Subject: bug#21020: 24.4; `display-time-world' tampers with TZ

From: Eli Zaretskii <[email-masked]>
Date: Sun, 26 Jul 2015 21:21:36 +0300

> Date: Sun, 26 Jul 2015 10:55:38 -0700
> From: Paul Eggert <[email-masked]>
> CC: [email-masked], [email-masked]
> 
> Eli Zaretskii wrote:
> 
> >> test/automated/icalender-tests.el exercises the new code.
> >
> > But the tests there that play with TZ are all expected failures on
> > MS-Windows, because they use Posix format of time-zone definition that
> > Windows runtime doesn't support.  So that probably means there are no
> > tests that could be used on Windows.
> 
> OK, didn't know that.  Presumably this could be addressed by adding tests for 
> MS-Windows TZ settings, if somebody has the time for this (pun intended...).

MS-Windows supports only the simplest TZ format, as in EST-5EDT, you
cannot tell it when the DST rules begin and end.  And those test
exercise precisely those begin/end rules that cannot work.

> >> Also, the MS-Windows port can't entirely skip the time module any
> >> more, as that module arranges for time.h to declare localtime_rz and
> >> friends.
> >
> > This could conflict with time.h in nt/inc/sys/, no?
> 
> I don't see why.  <sys/time.h> is a different API.  This patch affects only 
> <time.h>.
> 
> >lib/time.h seems to want to replace 'localtime', which might
> > clash with 'sys_localtime' we currently use as replacement on w32.
> 
> The replacement is conditional, and the condition should be false on w32.

Then I guess we are lucky, and nothing could possibly become broken.

Thanks.