"Do you really use this in conversations/emails etc?" Yup, and when (rare) people ask, I explain them the motivation. Might be due to the people I interact wit

"Do you really use this in conversations/emails etc?" Yup, and when (rare) people ask, I explain them the motivation. Might be due to the people I interact with though. As I said, this only pertains to remote meetings involving multiple individuals from across the globe, each staying at their own location. If you're scheduling a worldwide meeting with someone in another timezone and you say 14:00 CEST or Eu/Paris summer time or whatever they already have to deal with timezones. If it's your time they'll have to convert and risk missing some peculiar rule of your timezone, and if it's their, they will have to recognize it's their, and you take a risk converting it with a potentially outdated rule. As soon as you're talking timezones, you might as well go with UTC: you know how to convert your time in UTC, and they know how to convert UTC to theirs (and back). This completely obviates the need to know where your correspondent is and how time is managed there, and none of you have to care about which side of the globe the other is living in. Also, the thread-top post link misses a particularity of timezones. As mentioned above, one should probably mention timezones but e.g CET or CEST not by offsets like GMT+2 (where you don't know if it's CEST or EET). This way everyone knows what we're talking about: north/south and DST in effect or not. What's more, a properly maintained system should receive updates about the various changes of timezone DST settings. IIRC Russians had one not so long ago. Of course, if your system is not up to date, it has no means of knowing when the DST change will occur. "someone travels with their Blackberry and changes the time rather than the timezone" That's not a bug, that's a PEBKAC and no amount of software goodness will prevent that. Actually they probably do that because they usually manually enter their 4PM LA appointment when in NY Timezone, and if they changed the timezone the event would be offsetted to 2PM. They are essentially specifying time relative to them and not relative to UTC. Maybe they failed to notice they can do that or they did not bother to set the timezone of an event when creating it, and as soon as an event with the timezone set comes in, they're toast. Combined with the terrible pervasive expectation that software is always crap, they blame the software and fail to notice their mistake. Edit: Russian timezone update on e.g Debian: https://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/fd732cc69f129cc3/8791c8dd27efff6c?lnk=raot&fwc=1 https://groups.google.com/group/linux.debian.bugs.dist/brows... Notice how the system timezone file describes every timezone update, so that your calendar software can use it for your years old events.