Hello. Yes sorry i have no computers in my head at the moment.
Paul Eggert wrote in <[email protected]>: |On 8/6/26 14:22, Steffen Nurpmeso via tz wrote: |> If |> localtime and gmtime both refer to the same clock_gettime, then at |> maximum there can be "one day" difference | |The timestamps can be in different years. December 31 of one year, |January 1 of the next. Or vice versa. Yes. This is why i have said "thank you", because your observation was absolutely correct. The fixed code is rv = ((((localp_or_nil->tm_hour - utcp_or_nil->tm_hour) * 60) + (localp_or_nil->tm_min - utcp_or_nil->tm_min)) * 60) + (localp_or_nil->tm_sec - utcp_or_nil->tm_sec); if((t = (localp_or_nil->tm_yday - utcp_or_nil->tm_yday)) != 0){ if((t < 0 && localp_or_nil->tm_yday == 0) || t == 1) rv += S(s32,su_TIME_DAY_SECS); else rv -= S(s32,su_TIME_DAY_SECS); } and works as expected when i test UTC, Mexico/BajaSur (-700) as well as Asia/Kolkata (+0530) for the dates s=1767225599 #s=$((1767225599 + 7*60*60)) #s=$((1767225599 - (5*60*60 + 30*60))) plus the two follow-up seconds, respectively, which refer to the year change 2025/6 in each timezone. (For each of the three as via SOURCE_DATE_EPOCH=$s TZ=UTC $MAILX .. SOURCE_DATE_EPOCH=$s TZ=Mexico/BajaSur $MAILX .. SOURCE_DATE_EPOCH=$s TZ=Asia/Kolkata $MAILX .. etc etc etc.) |> there was a change due to the "Dublin |> stuff" | |I'm not seeing how the code you quoted handles negative DST, as in It was a bug report. I got a bug report of an Italian user who said Looking at the source of s-nail, I tracked it all down to a naive/incorrect handling of tm->tm_isdst in mkdate() in sendout.c (the same logic appears in other places, for example see the comment in src/mx/header.c that reads "/* TODO simply adding an hour for ISDST is .. buuh */".) Yeah the issue was known, but i hoped for SU tools.. whatever. After a lot of research (and I feel I've become an expert on the subject by now!) this is what I've found: In 2018, the tzdata maintainers (IANA) corrected a historical mistake with the Europe/Dublin timezone. The mistake was rooted in a misunderstanding of whether IST meant "Irish Summer Time" or "Irish Standard Time". etc etc (thanks, Andrea Biardi). (The problem had another problem, at another location it did not account for int->unsigned long extension, also such a concentration hole, since all other locations do the necessary cast.) |Europe/Dublin. Nor do I see how it handles DST offsets of 30 minutes, as |in Pacific/Rarotonga. Why not? This time i (hope and) think you are not concentrated. (But which is understandable.) |Again, look at the code in zdump.c that does this sort of thing, and if |there's something you don't understand please ask. Attempts to simplify |it without understanding it are likely to result in bugs. I did not understand why that goes over lengthy corners with leapyear calculcations, because within a single TZ the difference to UTC stays within the 24 hour limit, so the difference is maximally one day. I think the above is correct. --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)
