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/
