On 1/6/2024 11:34 AM, Michael H Deckers via tz wrote:
On 2024-01-05 23:31, Guy Harris via tz asked:
The binary file obviously allows code that reads it to get information of the form "at date/time DT, one or more of {the offset from UTC, whether tm_isdst should be zero or non-zero, the time zone abbreviation} changes". The tzcode doesn't happen to have APIs to*provide* that information, but that's a different matter.
Is there software that needs to know about transitions that change none of those?
... So are there Java classes read those files and use them?
Or are they files produced by Java code that*uses* the data?
Yes, there is information on local civil times scales needed by many datetime software interfaces that is already present in the tzdb source files but that is missing from the TZif files since the very beginning:
• the SAVE value (or the numeric RULES value) applicable at an instant is not available via TZif files, and cannot in general be deduced from its contents (see eg the SAVE value +01 h for Europe/Dublin when UT = 1916-10-01 + 02:25:21.1). It has even become more difficult to guess these values from TZif files since they are allowed to be negative.
• the RULEs applicable at a specific instant (if any). They are available in TZif files (in versions 2 and 3) only for recent instants, and the start of their applicability is only given indirectly in TZif files, sometimes requiring a redundant transition (which is the topic of this thread).
I think it would be very useful to have an official output of the tzdb data compilation process (zic and associated tools) that makes these data available for datetime software, even though they are not needed by the POSIX datetime functions.
Michael Deckers.
I agree, this would help. I think the difficulty originates with Posix-time itself which has no method to signal STDOFF, the isdst flag is insufficient to signal so-called "double summertime" or negative DST shifts and, of course, leap-seconds. This leaves TzDb responsible to 'trick' the Posix time (localtime() and mktime()) into yielding the Posix YMDhms representation (broken-down time) by manipulating gmtoff while holding stdoff to some fixed value. In common cases this works ok but in many situations, such as STDOFF shifts, STDOFF shifts simultaneous with DST shifts, or "double summertime" the TzIf values are essentially 'lying' to work around the Posix insufficiencies. Until Posix-time is improved TzDb will be forever inventing work-around manipulations of the Posix-time. One might hope the Posix folks might recognize this and find ways to address it. In the meantime I think including these kinds of "no-op" transitions would improve things. Zic does include many "no-op" transitions where only the abbreviation changes, such as New_York: -769395601 1945-08-14 18:59:59 isdst 1 gmtoff -14400 stdoff -18000 EWT -769395600 1945-08-14 19:00:00 isdst 1 gmtoff -14400 stdoff -18000 EPT I see no harm to typical behavior of Posix-time by providing these other "no-op" transitions to assist applications that can make use of them. -Brooks