Help With Understanding the Binary Files

[Bill Seymour]

(*sheesh*)

I was NOT asking about the number of local time types.

I was NOT asking about the difference between standard time and DST.

I was NOT asking how to make POSIX TZ strings.

I WAS asking about the two arrays that follow the leap second array
in the zoneinfo binaries...what does it mean to say that they're
"indexed by type", and what the heck do I do with the data in them?

--Bill


On Wed, Dec 9, 2009 at 12:02 PM, Guy Harris <guy at alum.mit.edu> wrote:
>
> On Dec 9, 2009, at 6:09 AM, Bill Seymour wrote:
>
>> Could somebody please help me interpret the tz
>> binary files?
>>
>> I'm having trouble understanding what to do with
>> the two arrays that follow the leap second array.
>>
>> 1.  tzfile.h says that they're "indexed by type";
>> but I don't see anything in the "type" (which I
>> take to mean what tzfile.5 calls "struct ttinfo")
>> that could be used as such an index.  Does
>> "indexed by type" mean "having the same index
>> as the type", in other words, the value from
>> the array following the transition time array?
>
> Yes.  The "number of local time types" is what's stored in the tzh_typecnt
> field, so the array of structures containing
>
>        coded UTC offset in seconds
>        tm_isdst value
>        abbreviation list index
>
> is indexed by the local time type (as it has tzh_typecnt elements), and the
> array following the transition time array is an array of "types of local
> time starting at above".
>
> See also "man tzfile" on UN*X systems that use the Olson code (and that
> bother to install the man page).
>
>> 2.  tzfile.h seems to imply that these booleans
>> indicate how I should interpret the values in
>> the array of transition times.  Is that correct?
>> If so, how do I calculate standard time while
>> DST is being observed given that the SAVE column
>> in the Rule has been lost?  Do I assume that the
>> offset for DST is always exactly 1 hour?
>
> No.  Presumably "standard time", at a time when DST is being observed, is
> what the time would have been had the most recent standard time -> DST
> transition not happened (note that the offset between GMT and *standard*
> time in a particular time zone can change over time, so it's not as if a
> given location has to remain at the same offset from GMT forever), so you
> should get the offset from GMT for the entry prior to the current entry.
>
>> 3.  tzfile.5 says that these "are used when a time
>> zone file is used in handling POSIX-style time zone
>> environment variables."  Does that mean that the
>> "transition times" are the ones in the TZ variable,
>
> No.
>
> It means that the TZ variable can be in one of the following forms:
>
>        :{pathname}, in which case the part of TZ after the : is the pathname
> of the time zone file to use - absolute if it begins with /, relative to the
> directory containing the zoneinfo files if it doesn't begin with /;
>
>        {something not beginning with :}, in which case the value of TZ in
> its entirety is used as a pathname, and if the pathname (again, absolute if
> it begins with /, relative to the directory containing the zoneinfo files if
> it doesn't begin with /) refers to a time zone file that can be read, that
> file is used, otherwise it's used as a POSIX-style time zone setting.
>
> If it's used as a POSIX-style time zone setting rather than as a file name,
> and the setting of TZ includes no transition rules, the time zone file
> "posixrules", in the directory containing the zoneinfo files, is used to
> specify when transitions between standard time and DST happen.  See the
> tzset man page:
>
>           rule         Indicates when to change to and back from summer
> time.
>                        The rule has the form:
>
>                              date/time,date/time
>
>                        where the first date describes when the change from
>                        standard to summer time occurs and the second date
>                        describes when the change back happens.  Each time
>                        field describes when, in current local time, the
>                        change to the other time is made.
>
>                        The format of date is one of the following:
>
>                        J n      The Julian day n (1 <= n <= 365).  Leap days
>                                 are not counted; that is, in all years --
>                                 including leap years -- February 28 is day
> 59
>                                 and March 1 is day 60.  It is impossible to
>                                 explicitly refer to the occasional February
>                                 29.
>
>                        n        The zero-based Julian day (0 <= n <= 365 ) .
>                                 Leap days are counted, and it is possible to
>                                 refer to February 29.
>
>                        M m.n.d  The d'th day (0 <= d <= 6) of week n of
> month
>                                 m of the year (1 <= n <= 5), (1 <= m <= 12),
>                                 where week 5 means ``the last d day in month
>                                 m'' which may occur in either the fourth or
>                                 the fifth week).  Week 1 is the first week
> in
>                                 which the d'th day occurs.  Day zero is Sun-
>                                 day.
>
>                                 The time has the same format as offset
> except
>                                 that no leading sign (`-') or (`+') is
>                                 allowed.  The default, if time is not given,
>                                 is 02:00:00.
>
>                        If no rule is present in the TZ specification, the
>                        rules specified by the tzfile(5)-format file
>                        posixrules in the system time conversion information
>                        directory are used, with the standard and summer time
>                        offsets from UTC replaced by those specified by the
>                        offset values in TZ.
>
>