[bug #60952] NSTimeZone fail to deal with tzfile v2+

[Emmanuel Dreyfus]

Follow-up Comment #2, bug #60952 (project gnustep):

Thank you for fixing it, unfortunately I overlooked a huge part of the
required support for tzfile v2+, and my fix worked by chance.

The Europe/Paris last transition is in 1996. After that date (or if there was
no transition at all), RFC 8536 says date should be computed using the last
TZstring of the footer.

The footer is after the v2+ data and is a list of nul-terminated strings. Here
is the example for Europe/Paris
00000400  00 00 00 0d 00 00 0e 10  00 11 00 00 1c 20 01 15  |.............
..|
00000410  00 00 1c 20 01 1a 4c 4d  54 00 50 4d 54 00 57 45  |...
..LMT.PMT.WE|
00000420  53 54 00 57 45 54 00 43  45 54 00 43 45 53 54 00 
|ST.WET.CET.CEST.|
00000430  57 45 4d 54 00 0a 43 45  54 2d 31 43 45 53 54 2c 
|WEMT..CET-1CEST,|
00000440  4d 33 2e 35 2e 30 2c 4d  31 30 2e 35 2e 30 2f 33 
|M3.5.0,M10.5.0/3|
00000450  0a                                                |.|
00000451

Last string is CET-1CEST,M3.5.0,M10.5.0/3 which is in the very versatile
format described in section 8.3 of POSIX base definitions
https://pubs.opengroup.org/onlinepubs/9699919799/

I hope you already have a parser for that. Here it means CET-1 until last
sunday of march (implicit hour 2:00), and CEST until last sunday of octobre
3:00, but there are more formats.

TZfile version 3 adds two extensions to this format, documented in RFC 8536
section 3.3.1. But at least it would be nice if v2 was supported, as v1 is
vulnerable to Y2038 bug.

I attached v2 Europe/Paris if you want to give it a try. You just have to drop
it in /usr/share/zoneinfo/Europe/Paris.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60952>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/