On Tue, Jun 5, 2012 at 9:16 PM, Nick Coghlan <ncogh...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
