[Python-Dev] tzset

[Guido van Rossum]

[Stuart]
> test_time.test_tzset should only be run if time.tzset is defined
> (which should only be there if configure determines that tzset works
> with the TZ formats we are testing). Feel like adding a clause at the
> top of test_tzset to skip the test if time.tzset is not defined, or
> should I submit a patch?

Done.

[Tim]
> > Now Windows does support tzset(), but not TZ values of the form
> > test_time.test_tzset() is testing, like
> >
> >                 environ['TZ'] = 'US/Eastern'
> > and
> >             environ['TZ'] = 'Australia/Melbourne'
> >
> > The rub here is that I haven't found *any* tzset man pages on the
> > web that claim TZ accepts such values (other than to silently
> > ignore them because
> 
> It specifies the pathname to a tzfile(5) format file, relative to
> a OS defined default. From BSD:
>      If its value does not begin with a colon, it is first used as
>      the pathname of a file (as described above) from which to
>      read the time conversion information.  If that file cannot be
>      read, the value is then interpreted as a direct specification
>      (the format is described below) of the time conversion
>      information.
> Solaris has a similar definition. Linux documents this format as
> needing to start with a ':' but accepts it (at least I think I
> tested this...)
> 
> To me, this is the useful format as all the others require you to
> know your DST transition times rather rely of the OS to supply them.
> At the moment if the 'path to a tzfile(5)' format is not accepted, your
> tzset(3) is considered broken and time.tzset not built.
> 
> I'm happy to rewrite the detection in configure.in and the test in
> test_time.py to lower the bar on this, but I think a better solution
> may be to determine if Windows has a format that lets us to DST
> calculations and keep the bar high. I was hoping that such a format
> would a) exist and b) Allow translation between the Unix standard of
> Country/Region to whatever-windows-uses.

Nevertheless I don't think that the standard definition for tzset()
defines which values will be accepted by a particular tzset
implementation.  So a test that relies on these is bound to fail on
systems, not because tzset is broken, but because the test makes
unfair assumptions.  Perhaps you can rewrite the test to use only
standardized input forms?

--Guido van Rossum (home page: http://www.python.org/~guido/)