On Thu, 22 Jul 2021, Emmanuel Dreyfus wrote:
I need some help reading it. zdump -i /usr/share/zoneinfo/Europe/Paris
reports 1108 transitions.
tzh_timecnt4 bytes @ 0x53 value 0x65 = 101 in decimal
tzh_timecnt is "coded number of transition times". How do I find 1108 for
tzh_timecnt?
I'm
On Wed, Jul 21, 2021 at 11:24:07AM +, RVP wrote:
> Seems deliberate. From tzfile(5):
I need some help reading it. zdump -i /usr/share/zoneinfo/Europe/Paris
reports 1108 transitions.
Here is the file:
54 5a 69 66 32 00 00 00 00 00 00 00 00 00 00 00 |TZif2...|
0010 00
Martin Husemann wrote:
> But overall: clearly a bug in gnustep, version 1 format files are obsolete.
A patch that fixes enough of the situation so that SOGo stops breaking
gmtoffsets:
https://savannah.gnu.org/bugs/index.php?60952
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
On Wed, 21 Jul 2021, Emmanuel Dreyfus wrote:
Copying a tzfile from Linux on NetBSD works around the problem in GNUstep,
and comparing the files, I notice a NetBSD weirdness as shown in
/usr/share/zoneinfo/Europe/Paris hexdump below:
54 5a 69 66 32 00 00 00 00 00 00 00 00 00 00 00 |T
On Wed, 21 Jul 2021, Emmanuel Dreyfus wrote:
Copying a tzfile from Linux on NetBSD works around the problem in GNUstep,
and comparing the files, I notice a NetBSD weirdness as shown in
/usr/share/zoneinfo/Europe/Paris hexdump below:
54 5a 69 66 32 00 00 00 00 00 00 00 00 00 00 00 |T
On Wed, Jul 21, 2021 at 11:24:07AM +, RVP wrote:
> For version-2-format timezone files, the above header and data are fol-
> lowed by a second header and data, identical in format except that eight
> bytes are used for each transition time or leap second time.
Also later:
[..] It
