[Datetime-SIG] Add a strftime/strptime code for timezone ID

Random832 random832 at fastmail.com
Thu Nov 3 10:51:39 EDT 2016


On Thu, Nov 3, 2016, at 10:20, Alexander Belopolsky wrote:
> My proposal was indeed prompted by the recent discussion on the IANA
> mailing list about human readable abbreviations being changed to numeric
> codes.  It is not uncommon for people to display timezones with '%Z %z'
> format which with recent changes would result in "+10 +1000" for say
> Asia/Vladivostok.  With the proposed %/ code, "%/ %z" would print
> "Asia/Vladivostok +1000" which looks like an improvement even over the
> original "VLAT +1000".

Surely it'd be better to support the CLDR mechanisms for timezone names
and abbreviations, and then %Z %z could print "Vladivostok Time +1000"
or "Владивосток +1000" (or perhaps "Vladivostok Standard Time +1000", 
"Владивосток, стандартное время +1000", or perhaps abbreviations could
be added to the CLDR Russian locales.) Done right, this would mean
people don't even need to change their format strings.

Supporting it in strptime is more dicey, but possible - maybe loading a
locale* in LC_TIME builds a trie with all the possible timezone names.
This would give you the metazone, and CLDR does define a notion of the
"primary" tzid for a metazone. It's even locale-sensitive -
America_Eastern maps to America/New_York by default, but America/Toronto
in canada, etc.

> The results of strftime() are not necessarily intended for displaying
> directly to end users.  An application can have an extra layer that
> translates tzids for display and the raw tzids may be useful for saving
> times in text files or a database.

It would probably be better to have a generic mechanism which could
include the tzid for tzid-based timezones, or some other identifier for
timezones that work a different way. And maybe a mechanism for
timezone-providing modules to be registered so that strptime or some
other mechanism knows how to reconstitute a timezone from such a
string... something that's missing from your proposal. Remember, Python
doesn't actually support IANA timezones out of the box.


*where? should setlocale do this even if datetime isn't loaded? do we
need a general mechanism for modules to install "set locale hooks"? Is
there a more appropriate place to discuss this? i18n-sig seems dead.


More information about the Datetime-SIG mailing list