always transmit and store times in UTC.
I don't think this is perfect. The issue is that the conversion between local and UTC involves the tz database (or similar) and that is a moving target. You can very well have tz_local_to_utc (t0, tzid, tzversion1) != tz_local_to_utc (t0, tzid, tzversion2), (after all, we would not need many versions of tz every year if that was not the case) and therefore tz_utc_to_local (tz_local_to_utc (t0, tzid, tzversion1), tzid, tzversion2) != t0. A possible scenario: create an appointment for a time in the future using tzversion1, store the UTC time, and later read the appointment using tzversion2; the time of the appointment may have changed. It is true that in many parts of the world, the likelihood of that scenario is low, but there are others where it's far less uncommon. Also note that the scenario applies equally well to client/server vs. local, one user creating and another reading vs. the same user doing both. Storing both local and UTC may not be the best to fix this, or not quite enough, because it does not tell you which of the two values is the authoritative one. I don't quite see any other solution than storing a time together with the timezone in which it is expressed. That time zone may be UTC. If you make an appointment for a meeting in Moscow, then you really want to store the local time (it does not matter much how that local time relates to UTC, you'd better be there when the local clocks say so); if you make an appointment for a teleconference with participants across the world, then you really want to store the UTC time, and let everyone figure out what it mean (or will mean) for them. That puts a burden on users of choosing the timezone, but fortunately, local time is a good default, and only those who deal with multiple time zones have to choose UTC. There is the subsidiary issue that what people really need is "the timezone of this location", rather than "this tz timezone". The difference shows up in the tz database whenever a new tz timezone is introduced. Fortunately, such changes are much less frequent. Eric.