[Python-Dev] Draft PEP for time zone support.

[Steve Dower]

Paul Moore wrote:
> On 12 December 2012 16:11, Brian Curtin <brian at python.org> wrote:
> > I don't think it's all that bad to include a small script on Windows
> > which runs every few days to check PyPI, then present an option to
> > update the info. This is what Java itself is doing anyway.
> 
> What would that do in an environment without internet access? Or with a
> firewall blocking Python's requests and returning an error page without
> warning (so the updater just sees incorrect data)? What about corporate
> environments that want to control the rollout of updates? (I can't imagine
> that in practice, but certainly companies do it for Java). Most Windows
> updaters use the "official" Windows APIs so that they work properly with
> odd cases like ISA proxies taking credentials from the Windows user login.
> Python's stdlib doesn't support that type of thing.
> 
> I'm -1 on auto-updating because it's too easy to produce a "nearly right"
> solution that doesn't work in highly-controlled (e.g.,
> corporate) environments. And a "correct" solution would be hard to support
> with python-dev's level of Windows expertise.

And what about embedded installations of Python, such as in TortoiseHg? And all the people (such as myself) who disable updaters that they don't like or didn't expect?

The "correct" solution on Windows may be to use a static database for historical dates and the information in the registry for current and future dates. The registry is updated through Windows Update, which is at least as reliable as anything Python could do. (I'm not sure exactly what the state of updates to older versions is like, but I'd assume WinXP still gets timezone updates and Win2K doesn't.)

Details of the registry entries are at http://msdn.microsoft.com/en-us/library/ms725481.aspx. It looks like the data is focused on modern timezones rather than localities, which would mean a many-to-one mapping from zoneinfo. Unfortunately it doesn't look like there's enough overlap to allow an automated mapping.

That said, it is incredibly easy to convert between UTC and local (http://msdn.microsoft.com/en-us/library/ms724949.aspx), even for dates in the past or future when the information is available. It's just that timezones other than the user's preference are difficult.

Cheers,
Steve