Why are timezone aware and naive datetimes not distinct classes?
nobody at nowhere.com
Sun Mar 10 00:38:37 CET 2013
On Sat, 09 Mar 2013 14:40:14 -0500, Roy Smith wrote:
> Future scheduled activities (which I assume is what you
> mean by "appointments") should be kept in whatever timezone makes sense
> for that activity. For example, I'm on NASA's mailing list to receive
> alerts when the ISS is going to be visible to the naked eye at my
> location. The last one said:
>> Time: Wed Feb 27 6:17 PM, Visible: 4 min, Max Height: 54 degrees,
>> Appears: W, Disappears: SE
> If I wanted to put that on my calendar, I really should convert it to
> UTC and record it that way.
Indeed; that is an appropriate use of UTC.
> Likewise, let's say I make an appointment to have a phone call with
> somebody in Caliornia (I'm in New York) at some future date. I put on
> my calendar "Call with Joe, 5 PM". Joe puts on his, "Call with Roy, 2
> PM". The idiots in Albany and/or Sacramento decide to mess with the
> timezones and one state changes the rules. We're going to miss our
> phone call. Had we both recorded the arranged time in UTC, we'd get to
> talk to each other.
Maybe. But if the time was chosen so as not to conflict with other
activites, changes to timezone(s) will often result in corresponding
changes to schedules, meaning that one or both parties will no longer be
available at the original UTC time (or even at any time, if both have busy
Which is why "future scheduled activities" which require multiple people
to physically meet at a specific place and time are normally scheduled
in terms of "the /de jure/ timezone of that location, as applicable on
that date", rather than in UTC or even a named timezone.
Similarly, the policies of a corporation which operates in multiple
timezones within a single country may dictate times which are common (in
HH:MM terms) to all locations but which are interpreted according to each
location's /de jure/ timezone (e.g. fast food chains' "breakfast" menus).
More information about the Python-list