Paul Eggert via tz wrote in <[email protected]>: |On 8/7/26 12:32, Steffen Nurpmeso wrote: |> within a single TZ the difference |> to UTC stays within the 24 hour limit | |I think that was to support very large DST offsets but you're right, if |you're not worried about that it's not an issue. I still don't see how |the code handles DST offsets not equal to 1 hour, though, as it seems to |have the 1 hour hard-coded.
Hm. Regarding your pointer to Pacific/Rarotonga. Many years ago that was, the topic you really refer to, do you, i have forgotten about all of that!! What conscious and extensive memory!!! It was about timezones which require "second-precision", in that for example witw $ date -d @-2216882247 -u Sun Oct 1 15:22:33 UTC 1899 $ TZ=Pacific/Rarotonga date -d @-2216882247 Mon Oct 2 04:43:29 LMT 1899 the struct tm::tm_sec of gmtime() and localtime() is not identical! Yes. Well the IETF had a lengthy and voluminous (from only the emails which i solely look at) discussion in the process of updating the "internet and time" topic, so to say, a couple of years ago that was, and i brought up this topic, yes. The problem being, and what i mostly thought about, that RFC 5322 for example does not support such divergences at all, but goes for [+-]HHMM only. If i recall correctly there then was a little bit of mail exchange on this, with my "last line of defend" being some certain structured comment that would carry the necessary additions, which then someone (i have forgotten, and i do not really keep an archive myself, that much, anymore) retorted with ~"such comments can be misinterpreted" or something. (They surely can also get lost along the way.) So that was then swept under the carpet. (Of course it is true that as of the time by then and now all such timezones have long been changed to not require such. But i think this can very well be a momentary thing.) Regarding the IETF that was surely the right thing to do, i think most of those do their very best to ensure that the places which had these oddities vanish as soon as possible under the rising levels of that ocean that you can see the sun go down over, i would think, which would obsolete the problem at the core. (In that these golden sunsets of California are of course one of these devastating postcard dreams that the american lifestyle hammered into our heads.) Yes, I'd only wish the "millions hordes" would be worth the trouble they cause, but so it is. So to chatter less, the MUA i maintain now says something like reproducible_build: The difference of UTC to local timezone $TZ requires second precision. reproducible_build: Unsupported by RFC 5321, henceforth using TZ=UTC to not loose precision! Oh -- that is a [Sigmund] Freud'scher fault, it says 5321!! It should say 5322, of course. Honor to whom honor is due. A nice Sunday i wish. Ciao, and greetings from Germany. P.S.: what would be really cool would be some [test timezone, and an] additional file like that tzdata.zi -- which i think is a really great thing to have! -- that gives epoch-seconds and resulting gmtoffs, maybe timezone abbrevs, etc. You know, certain problematic corner cases that software should be capable to deal with, and the correct results. I used some Mexico and Indian thing yesterday after looking at tzdata.zi, but at least in theory this could all be in flux, and "a carefully chosen epoch second" will still hang in the air if later IANA TZ versions change that past value, because it was erroneous. So if i run "zdump -T" i would get this list for example. I do not know, but had this thought crossing my mind. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
