[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