[Python-Dev] TZ-aware local time

Alexander Belopolsky alexander.belopolsky at gmail.com
Wed Jun 6 03:39:07 CEST 2012


On Tue, Jun 5, 2012 at 9:16 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> ...  Local time should only be used for displaying
> dates and times to humans (since we care about little things like
> local sunrise and sunset, local business hours, etc) and for
> inter-system coordination where such details are relevant.
>

Displaying local time would be addressed by what I called the first
feature: given the timestamp find the local time and the TZ
name/offset:

$ date
Tue Jun  5 21:28:21 EDT 2012

Most humans will ignore the TZ information, but the format above can
represent any moment in time unambiguously.

A related but different problem is taking time input from humans.  Air
traffic control systems may handle all times in UTC, but when I search
for my flight, I enter local time.  There may be two flights one at
1:30 AM EDT and the other at 1:30 AM EST.  In this case I need some
way to figure out which one is mine and I will look at the TZ part.
(Hopefully the user interface will present a helpful explanation of
what is going on.)


> The datetime module should be designed to make this *as easy as
> possible*. Adding a "local time" tzinfo object (with the ambigous hour
> favouring the non-DST time, and the missing hour triggering an error
> at construction time) would be a good step in the right direction: it
> allows local times to be clearly flagged, even though they're
> explicitly *not* appropriate for many kinds of processing and need to
> be converted to a more suitable format (such as a naive datetime
> object, or one with the timezone set to UTC) first.

This is exactly my proposal, but it does not help when you need to get
on the right 1:30 AM flight.


More information about the Python-Dev mailing list