OK, so I'm making some progress on my library. I'm attempting to read the timezone information for America/Kentucky/Louisville. When I run through the values for transition times, I get 177 values such as follows: 2661690496, 2693140096, 2759063296, ... The docs say these transition times are in values returned by the c time function, which returns seconds since midnight, 1/1/1970. If that is the case, then the three values above convert to: May 6, 2054 at 2:28:16 PM May 5, 2055 at 2:28:16 PM June 6, 2057 at 2:28:16 PM These are nowhere near the DST conversion dates for these years and are moving forward. This appears incorrect. Can someone show me what I'm doing wrong? Thanks.
Thom Hehl wrote:
2661690496, 2693140096, 2759063296, ...
You've interpreted a signed 32-bit field as unsigned. 2661690496 is really -1633276800, which is 1918-03-31T08:00:00Z, which corresponds to Rule US 1918 1919 - Mar lastSun 2:00 1:00 D in 1918 with a -6:00 standard offset as called for by Zone America/Kentucky/Louisville -5:43:02 - LMT 1883 Nov 18 12:16:58 -6:00 US C%sT 1921 and similarly for the others. tzfile(5) says the field is "of type long", which in C is implicitly a signed type; unsigned would have to be explicitly stated. You might find the 64-bit version of the offsets clearer, where instead of the 0x9ea62c80 that you're misinterpreting you'll see 0xffffffff9ea62c80. -zefram
On 2011-11-07 19:25, Zefram wrote:
tzfile(5) says the field is "of type long", which in C is implicitly a signed type; unsigned would have to be explicitly stated.
As an aside, maybe tzfile.5 should use exact-width integer type names from C99 stdint.h, such as "int32_t" instead of "long". This would be useful for the description of the in-file layout of the ttinfo array members, where the one-byte tt_isdst and tt_abbrind members are described as being of type "int" and "unsigned int" respectively. As an other aside, is there a better way to describe the in-file layout of the ttinfo array members than using a C struct? An actual C struct would have padding and alignment requirements that do not agree with the in-file layout description. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
As an other aside, is there a better way to describe the in-file layout of the ttinfo array members than using a C struct? An actual C struct would have padding and alignment requirements that do not agree with the in-file layout description.
A data layout diagram, just like a packet format diagram in a network protocol spec, would be a good way to do that. It would make the layout completely explicit, without any question of the meaning of C type names or the platform-dependent rules of structure padding. paul
Ian Abbott wrote:
As an aside, maybe tzfile.5 should use exact-width integer type names from C99 stdint.h, such as "int32_t" instead of "long".
I think it would make more sense to excise the C terminology in favour of file format terminology: "four-byte big-endian signed integer".
As an other aside, is there a better way to describe the in-file layout of the ttinfo array members than using a C struct?
Exactly what follows the struct code: Each structure is written as a four-byte value for tt_gmtoff of type long, in a standard byte order, followed by a one- byte value for tt_isdst and a one-byte value for tt_abbrind. In file format terminology, that would be: Each ttinfo structure consists of a four-byte big-endian signed integer tt_gmtoff, a one-byte signed integer tt_isdst, and a one-byte unsigned integer tt_abbrind. Actually signedness of tt_isdst is rather irrelevant, since the only values actually used are 0 and 1, so it may be better to describe that as a truth-value type. -zefram
On 2011-11-08 11:45, Zefram wrote:
Ian Abbott wrote:
As an other aside, is there a better way to describe the in-file layout of the ttinfo array members than using a C struct?
Exactly what follows the struct code:
Each structure is written as a four-byte value for tt_gmtoff of type long, in a standard byte order, followed by a one- byte value for tt_isdst and a one-byte value for tt_abbrind.
In file format terminology, that would be:
Each ttinfo structure consists of a four-byte big-endian signed integer tt_gmtoff, a one-byte signed integer tt_isdst, and a one-byte unsigned integer tt_abbrind.
Once it has been established in the introductory matter that all integers are in big-endian order, there would be no need to specify that for individual fields. The introductory matter should also specify that signed integers are stored in 2's complement format. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Zefram said:
As an aside, maybe tzfile.5 should use exact-width integer type names from C99 stdint.h, such as "int32_t" instead of "long".
One issue is that the exact-width integer types don't exist on all systems and so aren't required by C99.
I think it would make more sense to excise the C terminology in favour of file format terminology: "four-byte big-endian signed integer".
"octet", not "byte", please. I do much of my day job on a machine with a 16 bit byte, and the rest on a machine with a 24 bit byte. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On 2011-11-08 12:14, Clive D.W. Feather wrote:
Zefram said:
As an aside, maybe tzfile.5 should use exact-width integer type names from C99 stdint.h, such as "int32_t" instead of "long".
One issue is that the exact-width integer types don't exist on all systems and so aren't required by C99.
Well it would just be for documentation purposes to describe the layout rather than for implementation purposes. The in-file ttinfo array can't (typically or portably) be represented by an actual array of a C struct type anyway. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
I think the documentation is sufficient in this regard. I had no problem understanding the width of the individual values, and putting the c types in is only helpful if you're using C. -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Ian Abbott Sent: Tuesday, November 08, 2011 7:26 AM To: tz@iana.org Subject: Re: [tz] Decoding timezone data On 2011-11-08 12:14, Clive D.W. Feather wrote:
Zefram said:
As an aside, maybe tzfile.5 should use exact-width integer type names from C99 stdint.h, such as "int32_t" instead of "long".
One issue is that the exact-width integer types don't exist on all systems and so aren't required by C99.
Well it would just be for documentation purposes to describe the layout rather than for implementation purposes. The in-file ttinfo array can't (typically or portably) be represented by an actual array of a C struct type anyway. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
participants (5)
-
Clive D.W. Feather -
Ian Abbott -
Paul_Koning＠Dell.com -
Thom Hehl -
Zefram