[tz] zic changes (2/2)

[Guy Harris]

On Mar 3, 2016, at 7:56 AM, Aurelien Jarno <aurelien at aurel32.net> wrote:

> On 2016-03-02 16:59, Guy Harris wrote:
>> On Mar 2, 2016, at 2:41 PM, Aurelien Jarno <aurelien at aurel32.net> wrote:
>> 
>>> It happens that this patch causes the generated zoneinfo files to not
>>> behave correctly wrt daylight saving time on 32-bit machines. On 64-bit
>>> machines or before this patch one get:
>>> 
>>> $ TZ=PST+8PDT date --date=@1152995400
>>> Sat Jul 15 13:30:00 PDT 2006
>>> 
>>> With this patch on 32-bit machines, one get:
>>> 
>>> $ TZ=PST+8PDT date --date=@1152995400
>>> Sat Jul 15 12:30:00 PST 2006
>>> 
>>> As you can see the daylight saving time is not applied.
>> 
>> What happens with TZ=PST8PDT?
> 
> This works as expected.

...because it finds a tzdb file named "PST8PDT".

>>> I don't know if it is a problem in zic or a problem on the GNU libc
>>> which doesn't correctly interpret the file. This is reproducible with
>>> GNU libc from git as the date of today.
>> 
>> What happens if you remove the PST8PDT link to America/Los_Angeles and use "TZ=PST8PDT"?
> 
> It doesn't seems that PST8PDT is a link to America/Los_Angeles, here it
> is is a different file. That said after removing the file using
> TZ=PST8PDT starts to show the same issue as with PST+8PDT, that is:
> 
> $ TZ=PST8PDT date --date=@1152995400
> Sat Jul 15 12:30:00 PST 2006

As I expected.

>> What happens if you remove a link for some zone east of Greenwich and try *that* zone's POSIX specification?
> 
> I am not really sure what you mean here. Something like removing the MET
> file and trying to use for example the MET-1METDST timezone?

Yes, that's what I meant, if "the MET file" is a file whose name is "MET-1METDST".

> In that case I get the correct output with and without the file:
> 
> $ TZ=MET-1METDST date --date=@1152995400
> Sat Jul 15 22:30:00 METDST 2006

So you removed a time zone file named "MET-1METDST" and then ran that date command, and it reported a time in DST?