<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 1/7/2024 5:48 PM, Paul Eggert wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b95741a6-e963-419f-9303-5f14e0bba4c1@cs.ucla.edu">On
2024-01-07 12:01, Brooks Harris wrote: <br>
<br>
<blockquote type="cite">Zic and TzIf reflect this change as a
shift in gmtoff, not stdoff: <br>
<br>
57722399 1971-10-31 02:59:59 isdst 0 gmtoff 3600
stdoff 0 BST <br>
57722400 1971-10-31 02:00:00 isdst 0 gmtoff 0 stdoff 0
GMT <br>
<br>
That's what I mean by "adjusted" for Posix sake. It gives the
proper UTC offset, yes, but not for the right reason. The
underlying reason was an STDOFF shift, presumably stated in the
law behind it. <br>
</blockquote>
<br>
I'm still not following this, unfortunately. <br>
</blockquote>
I'll try again.<br>
<blockquote type="cite"
cite="mid:b95741a6-e963-419f-9303-5f14e0bba4c1@cs.ucla.edu"> <br>
The use cases you gave mostly involved comparing local-time
timestamps when their UT offsets are known, and obviously gmtoff
suffices for that. You mentioned one use case for which the POSIX
API is ill-designed (namely, "find the next gmtoff transition"),
but gmtoff suffices for that too: we don't need stdoff there
either. <br>
</blockquote>
There are couple intermingled topics in the thread.<br>
<br>
-------------------<br>
A) Regarding if zone eras with UNTIL times with only a year
designation should be included in zic output.<br>
<br>
I think they should be. Take for example <font face="monospace">America/New_York:</font><br>
<br>
<font face="monospace"># Zone NAME STDOFF RULES
FORMAT [UNTIL]<br>
Zone America/New_York -4:56:02 - LMT 1883 Nov 18 12:03:58<br>
-5:00 US E%sT 1920<br>
-5:00 NYC E%sT 1942<br>
-5:00 US E%sT 1946<br>
-5:00 NYC E%sT 1967<br>
-5:00 US E%sT<br>
<br>
</font>There are four transitions at the 1st-of-the-year, each
changing the RULES field. <br>
<br>
Why is this important? In my implementations I find the date of a
transition, the transition type (STDOFF, dstoff, or leap-seconds),
the value of the transition shift, and the time-of-day of the shift.
Thus an application that has no access to metadata (TZIf, Posix-time
or anything else) can confidently represent any point within that
day from metadata contained in the timestamps themselves. I gave
this example in a response to Guy's similar question in this thread:<br>
<br>
<span style="white-space: pre-wrap">Example - A "fall back" DST transition in America/New_York:</span>
<pre class="moz-quote-pre" wrap="">D2022-11-06T00:00:00U-04Zamerica/new_yorkAedtV2021aL27S01t-01a02cMuX UTC 01667707227
D2022-11-06T01:59:59U-04Zamerica/new_yorkAedtV2021aL27S01t-01a02cMuX UTC 01667714426
D2022-11-06T01:00:00U-05Zamerica/new_yorkAestV2021aL27S00t-01a02cMuX UTC 01667714427
D2022-11-06T23:59:59U-05Zamerica/new_yorkAestV2021aL27S00t-01a02cMuX UTC 01667797226
^^^^ ^^^^^^^^^^
"gmtoff" DST transition metadata
</pre>
To accomplish this the application must search the transitions
backwards (previous transition) to discover STDOFF shifts and
forward (next transition) to discover if and when a DST or
leap-second transition is to occur. If these 1st-of-the-year
transitions are not included in the transition list the searches
will return the wrong transition and fail. <br>
<br>
I've modified my implementation of outzone() and **optimize of
writezone() to retain these 1st-of-the-year transitions. This
results in their being included in the TZIf files but this does not
alter the normal behavior localtime() because these are essentially
"no-op" transitions.<br>
<br>
-------------------<br>
B) Regarding stdoff, gmtoff, and Isdst <br>
<br>
gmtoff is the sum of STDOFF and any DST values in effect. This gives
the appropriate and important offset to normalize to UTC but it
confounds the two factors.<br>
<br>
I think the STDOFF value is critical. It essentially defines the
(approximate) longitude of the idealized time zone independent of
any DST shifts applied. And, regardless of longitude, it also
defines the *base* offset from UTC in the time domain whether or not
any DST shifts are in effect.<br>
<br>
As noted elsewhere, the isdst flag is insufficient in cases of
"double summertime". (And nothing says you couldn't have "triple
summertime " or "quadruple summertime"). You'd really like a
"dstoff" variable to carry this value, including negative DST
(Dublin and such).<br>
<br>
Then there is leap-seconds. This is a third offset factor indicating
the leap-seconds value. Lets call it "lsoff".<br>
<br>
So you'd have stdoff + dstoff + lsoff = gmtoff.<br>
<br>
So in my view its not only a matter of arriving at gmtoff, which is
critical of course, but that the other factors, stdoff, dstoff, and
lsoff be included in the timestamp. To do this would significantly
alter TZif, ideally would also be incorporated in Posix-time struct
tm, and should probably also be added to ISO 8601 representations.
I'm not sure if all this is feasible but I think if these topics are
not addressed a truly unambiguous timestamp is not possible because
the formats are incomplete.<br>
<br>
By the way, the term "standard" is somewhat ambiguous where in some
places it may refer to "wall clock time" whether DST is in effect or
not, as noted in another thread on the list. Its ok within the
context of TzDb because we are familiar with its meaning. But I
think there really should be a better term, such as "normal time",
or "primary offset".<br>
<br>
Also, DST shifts might not actually refer to "daylight saving"
shifts but might be used for some other reason. So, more generally,
these might be seen as "secondary offsets" (secondary to the primary
stdoff value). <br>
<br>
<blockquote type="cite"
cite="mid:b95741a6-e963-419f-9303-5f14e0bba4c1@cs.ucla.edu"> <br>
Also, it's often not the case that the underlying reason was
stated in the law behind it. The laws often don't specify this
information, or the laws simply aren't available (we're relying on
secondary sources), and in these cases I just made up internal
details like stdoff to make the POSIX-visible timestamp info
correct. <br>
<br>
APIs should not be exposing juryrigged internal details to the
user, as many of these details are simply my invention and do not
reflect known legislation. <br>
</blockquote>
OK. From an interoperability point of view I see TzDb source data to
be *the law*, whether backed by official documentation or invented
for convenience or otherwise. Without your "inventions" a lot of
this might not work. Thanks!<br>
<br>
Thanks,<br>
-Brooks<br>
</body>
</html>