[Python-Dev] TZ-aware local time (original) (raw)

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