- tz - lists.iana.org

[PROPOSED 1/2] Default time_t to 64 bits on glibc 2.34+ 32-bit
by Paul Eggert Oct. 26, 2022

Oct. 26, 2022

* NEWS: Mention this. * private.h (_TIME_BITS): Default to 64. --- NEWS | 8 ++++++++ private.h | 12 ++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index bddbd3da..a918aed2 100644 --- a/NEWS +++ b/NEWS @@ -57,6 +57,14 @@ Unreleased, experimental changes number 2438 comes from the 32-bit limit in the year 2038, plus the 400-year Gregorian cycle. (Problem reported by Bradley White.) + On glibc 2.34 and later, which optionally supports 64-bit time_t + on platforms like x86 where time_t was traditionally 32 bits, + default time_t to 64 instead of 32 bits. This lets functions like + localtime support timestamps after the year 2038, and fixes + year-2038 problems in zic when accessing files dated after 2038. + To continue to limit time_t to 32 bits on these platforms, use + "make CFLAGS='-D_TIME_BITS=32'". + In C code, prefer C23 keywords to pre-C23 macros for alignof, bool, false, and true. Also, use the following C23 features if available: __has_include, unreachable. diff --git a/private.h b/private.h index c185d5f3..2c7535d8 100644 --- a/private.h +++ b/private.h @@ -127,8 +127,9 @@ /* Enable strtoimax on pre-C99 Solaris 11. */ #define __EXTENSIONS__ 1 -/* To avoid having 'stat' fail unnecessarily with errno == EOVERFLOW, - enable large files on GNUish systems ... */ +/* Although tzcode does not call 'stat'-like functions directly, stdio + functions may call them. To avoid having them fail unnecessarily + with errno == EOVERFLOW, enable large files on GNUish systems ... */ #ifndef _FILE_OFFSET_BITS # define _FILE_OFFSET_BITS 64 #endif @@ -137,6 +138,13 @@ /* ... and enable large inode numbers on Mac OS X 10.5 and later. */ #define _DARWIN_USE_64_BIT_INODE 1 +/* On GNUish systems where time_t might be 32 or 64 bits, use 64. + This supports a wider time range, and avoids having 'stat'-like + functions fail unnecessarily with errno == EOVERFLOW. */ +#ifndef _TIME_BITS +# define _TIME_BITS 64 +#endif + /* ** Nested includes */ -- 2.37.2

1 1

Re: [tz] tz Digest, Vol 133, Issue 32
by richa＠msn.com Oct. 24, 2022

Oct. 24, 2022

Once again, "All problems in computer science can be solved by another level of indirection." ________________________________ From: tz <tz-bounces(a)iana.org> on behalf of tz-request(a)iana.org <tz-request(a)iana.org> Sent: Monday, October 24, 2022 7:00 AM To: tz(a)iana.org <tz(a)iana.org> Subject: tz Digest, Vol 133, Issue 32 Send tz mailing list submissions to tz(a)iana.org To subscribe or unsubscribe via the World Wide Web, visit https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.… or, via email, send a message with subject or body 'help' to tz-request(a)iana.org You can reach the person managing the list at tz-owner(a)iana.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tz digest..."

1 0

[PROPOSED 1/2] zic now supports links to links
by Paul Eggert Oct. 24, 2022

Oct. 24, 2022

* NEWS, backward, zic.8: Mention this. * zic.c (make_links): New function, which supports links to later links. In this function, improve quality of warnings about links to links. (main): Use it. --- NEWS | 14 ++++++++ backward | 6 ++-- zic.8 | 29 ++++++++++++++--- zic.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++++-------- 4 files changed, 126 insertions(+), 20 deletions(-) diff --git a/NEWS b/NEWS index 64a2d0c..f400d71 100644 --- a/NEWS +++ b/NEWS @@ -5,6 +5,7 @@ Unreleased, experimental changes Briefly: Move links to 'backward'. In vanguard form, GMT is now a Zone and Etc/GMT a link. + zic now supports links to links. Simplify four Ontario zones into one. Fix a Y2438 bug when reading TZif data. @@ -28,6 +29,19 @@ Unreleased, experimental changes Changes to code + zic now supports links to links regardless of input line order. + For example, if Australia/Sydney is a Zone, the lines + Link Australia/Canberra Australia/ACT + Link Australia/Sydney Australia/Canberra + now work correctly, even though the shell commands + ln Australia/Canberra Australia/ACT + ln Australia/Sydney Australia/Canberra + would fail because the first command attempts to use a link + Australia/Canberra that does not exist until after the second + command is executed. Previously, zic had unspecified behavior if + a Link line's target was another link, and zic often misbehaved if + a Link line's target was a later Link line. + Fix line number in zic's diagnostic for a link to a link. Fix a bug that caused localtime to mishandle timestamps starting diff --git a/backward b/backward index 101cbc0..4c1c5d5 100644 --- a/backward +++ b/backward @@ -17,9 +17,9 @@ # backward compatibility link. Each section is sorted by link name. # A "#= TARGET1" comment labels each link inserted only because some -# .zi parsers mishandle links to links. The comment says what the -# target would be if these parsers were fixed so that data could -# contain links to links. For example, the line +# .zi parsers (including tzcode through 2022e) mishandle links to links. +# The comment says what the target would be if these parsers were fixed +# so that data could contain links to links. For example, the line # "Link Australia/Sydney Australia/ACT #= Australia/Canberra" would be # "Link Australia/Canberra Australia/ACT" were it not that data lines # refrain from linking to links like Australia/Canberra, which means diff --git a/zic.8 b/zic.8 index e46d0ab..f79148f 100644 --- a/zic.8 +++ b/zic.8 @@ -190,7 +190,10 @@ the named file rather than in the standard location. Be more verbose, and complain about the following situations: .RS .PP -The input specifies a link to a link. +The input specifies a link to a link, +something not supported by some older parsers, including +.B zic +itself through release 2022e. .PP A year that appears in a data file is outside the range of representable years. @@ -691,19 +694,37 @@ The .B TARGET field should appear as the .B NAME -field in some zone line. +field in some zone line or as the +.B LINK-NAME +field in some link line. The .B LINK-NAME field is used as an alternative name for that zone; it has the same syntax as a zone line's .B NAME field. +Links can chain together, although the behavior is unspecified if a +chain of one or more links does not terminate in a Zone name. +A link line can appear before the line that defines the link target. +For example: +.sp +.ne 3 +.nf +.in +2m +.ta \w'Zone\0\0'u +\w'Greenwich\0\0'u +Link Greenwich G_M_T +Link Etc/GMT Greenwich +Zone Etc/GMT\0\00\0\0\*-\0\0GMT +.sp +.in +.fi +The two links are chained together, and G_M_T, Greenwich, and Etc/GMT +all name the same zone. .PP Except for continuation lines, lines may appear in any order in the input. However, the behavior is unspecified if multiple zone or link lines -define the same name, or if the source of one link line is the target -of another. +define the same name. .PP The file that describes leap seconds can have leap lines and an expiration line. diff --git a/zic.c b/zic.c index 82e1a4d..78afa67 100644 --- a/zic.c +++ b/zic.c @@ -678,6 +678,89 @@ bsearch_linkcmp(void const *key, void const *b) return strcmp(key, m->l_linkname); } +/* Make the links specified by the Link lines. */ +static void +make_links(void) +{ + ptrdiff_t i, j, nalinks; + qsort(links, nlinks, sizeof *links, qsort_linkcmp); + + /* Ignore each link superseded by a later link with the same name. */ + j = 0; + for (i = 0; i < nlinks; i++) { + while (i + 1 < nlinks + && strcmp(links[i].l_linkname, links[i + 1].l_linkname) == 0) + i++; + links[j++] = links[i]; + } + nlinks = j; + + /* Walk through the link array making links. However, + if a link's target has not been made yet, append a copy to the + end of the array. The end of the array will gradually fill + up with a small sorted subsequence of not-yet-made links. + nalinks counts all the links in the array, including copies. + When we reach the copied subsequence, it may still contain + a link to a not-yet-made link, so the process repeats. + At any given point in time, the link array consists of the + following subregions, where 0 <= i <= j <= nalinks and + 0 <= nlinks <= nalinks: + + 0 .. (i - 1): + links that either have been made, or have been copied to a + later point point in the array (this later point can be in + any of the three subregions) + i .. (j - 1): + not-yet-made links for this pass + j .. (nalinks - 1): + not-yet-made links that this pass has skipped because + they were links to not-yet-made links + + The first subregion might not be sorted if nlinks < i; + the other two subregions are sorted. This algorithm does + not alter entries 0 .. (nlinks - 1), which remain sorted. + + If there are L links, this algorithm is O(C*L*log(L)) where + C is the length of the longest link chain. Usually C is + short (e.g., 3) though its worst-case value is L. */ + + j = nalinks = nlinks; + + for (i = 0; i < nalinks; i++) { + struct link *l; + + eat(links[i].l_filenum, links[i].l_linenum); + + /* If this pass examined all its links, start the next pass. */ + if (i == j) + j = nalinks; + + /* Make this link unless its target has not been made yet. */ + l = bsearch(links[i].l_target, &links[i + 1], j - (i + 1), + sizeof *links, bsearch_linkcmp); + if (!l) + l = bsearch(links[i].l_target, &links[j], nalinks - j, + sizeof *links, bsearch_linkcmp); + if (!l) + dolink(links[i].l_target, links[i].l_linkname, false); + else { + /* The link target has not been made yet; copy the link to the end. */ + links = growalloc (links, sizeof *links, nalinks, &nlinks_alloc); + links[nalinks++] = links[i]; + } + + if (noise && i < nlinks) { + if (l) + warning(_("link %s targeting link %s mishandled by pre-2023 zic"), + links[i].l_linkname, links[i].l_target); + else if (bsearch(links[i].l_target, links, nlinks, sizeof *links, + bsearch_linkcmp)) + warning(_("link %s targeting link %s"), + links[i].l_linkname, links[i].l_target); + } + } +} + /* Simple signal handling: just set a flag that is checked periodically outside critical sections. To set up the handler, prefer sigaction if available to close a signal race. */ @@ -992,19 +1075,7 @@ _("%s: invalid time range: %s\n"), continue; outzone(&zones[i], j - i); } - /* - ** Make links. - */ - if (noise) - qsort(links, nlinks, sizeof *links, qsort_linkcmp); - for (i = 0; i < nlinks; ++i) { - eat(links[i].l_filenum, links[i].l_linenum); - dolink(links[i].l_target, links[i].l_linkname, false); - if (noise - && bsearch(links[i].l_target, links, nlinks, sizeof *links, - bsearch_linkcmp)) - warning(_("link to link")); - } + make_links(); if (lcltime != NULL) { eat(COMMAND_LINE_FILENUM, 1); dolink(lcltime, tzdefault, true); -- 2.37.3

1 1

Pacific islands as identifiers
by Paul-Cathy Unger Oct. 22, 2022

Oct. 22, 2022

Hi, I was recently setting the time zone on my computer to my current location -- Honiara, Solomon Islands. In my operating system's drop-down list of "Cities" (I use a Linux distro based on Ubuntu), I could not find Honiara. I finally ended up clicking on the map approximately where I thought it would be. To my surprise, where I clicked had the label "Guadalcanal". I wasn't expecting that, and certainly wasn't looking for Guadalcanal in the list -- Honiara would have made a lot more sense to me (e.g., https://www.timeanddate.com/time/zone/solomon-islands) I'm wondering what the rationale is for using island / province names for some Pacific nations and city names for others (e.g., Apia, Samoa; Port Moresby, PNG)? And I wonder if knowing that there are historic animosities in a country between people from one island and another would be enough to consider changing an apparent favouring of one island over another? For a brief and somewhat current analysis, see https://www.csis.org/analysis/deep-roots-solomon-islands-ongoing-political-…. I offer this for your kind consideration, Paul Unger

2 1

[PROPOSED 1/7] Port better to C23 bool
by Paul Eggert Oct. 20, 2022

Oct. 20, 2022

* private.h (HAVE_STDBOOL_H): Remove. (true, false, bool): Simply rely on __STDC_VERSION__. There’s no longer need to treat pre-C99 compilers with <stdbool.h> specially, as they can be treated as if they lack <stdbool.h>. --- Makefile | 1 - NEWS | 3 +++ private.h | 10 +++------- 3 files changed, 6 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 156840e..afe7af7 100644 --- a/Makefile +++ b/Makefile @@ -223,7 +223,6 @@ LDLIBS= # -DHAVE_POSIX_DECLS=0 if your system's include files do not declare # functions like 'link' or variables like 'tzname' required by POSIX # -DHAVE_SNPRINTF=0 if your system lacks the snprintf function -# -DHAVE_STDBOOL_H if you have a non-C99 compiler with <stdbool.h> # -DHAVE_STDINT_H if you have a non-C99 compiler with <stdint.h> # -DHAVE_STRFTIME_L if <time.h> declares locale_t and strftime_l # -DHAVE_STRDUP=0 if your system lacks the strdup function diff --git a/NEWS b/NEWS index 164ab95..16f454c 100644 --- a/NEWS +++ b/NEWS @@ -37,6 +37,9 @@ Unreleased, experimental changes number 2438 comes from the 32-bit limit in the year 2038, plus the 400-year Gregorian cycle. (Problem reported by Bradley White.) + Take advantage of the following C23 features if available: + bool/true/false keywords. + Release 2022e - 2022-10-11 11:13:02 -0700 diff --git a/private.h b/private.h index 9c31ec5..058d3c0 100644 --- a/private.h +++ b/private.h @@ -74,10 +74,6 @@ # define HAVE_POSIX_DECLS 1 #endif -#ifndef HAVE_STDBOOL_H -# define HAVE_STDBOOL_H (199901 <= __STDC_VERSION__) -#endif - #ifndef HAVE_STRDUP # define HAVE_STRDUP 1 #endif @@ -623,12 +619,12 @@ time_t time2posix_z(timezone_t, time_t) ATTRIBUTE_PURE; ** Finally, some convenience items. */ -#if HAVE_STDBOOL_H -# include <stdbool.h> -#else +#if __STDC_VERSION__ < 199901 # define true 1 # define false 0 # define bool int +#elif __STDC_VERSION__ < 202311 +# include <stdbool.h> #endif #define TYPE_BIT(type) (sizeof(type) * CHAR_BIT) -- 2.37.3

1 6

[PATCH 0/5] Simplifying Link line maintenance
by Paul Eggert Oct. 17, 2022

Oct. 17, 2022

Although TZDB currently puts most Link lines in the ‘backward’ file, some Link lines reside in the continental files ‘africa’, ‘antarctica’, etc., with little rhyme or reason as to which lines are in ‘backward’ and which line are in a continental file. This is confusing and makes maintenance a bit more difficult. This proposed series of patches aims to regularize this by putting the Link lines into ‘backward’, except that to work around a TZUpdater bug the GMT Link line is in ‘backward’ only when using vanguard form. As part of these patches, the Link lines in ‘backward’ are organized into sections that better explain the reason for each Link line. Also, comments are added to document shortcut Link lines, that is, Link lines reworded to reference the target rather than the source of another Link line. Furthermore, the Makefile is augmented to check Link lines more carefully. The overall effect of this patch is to shrink TZDB’s source code and make maintenance simpler and more robust, without affecting data except for users who are purposely bleeding-edge by omitting all backward-compatibility links. Because these patches are nontrivial I have not installed them in the development repository, and there is no rush. Comments welcome as usual. Paul Eggert (5): Move a few links to ‘backward’ Move most remaining links to ‘backward’ Reorder 'backward’ Improve checking for shortcut links Coalesce some commentary Makefile | 6 +- NEWS | 17 +++ africa | 213 ++++++++++-------------------------- antarctica | 2 +- asia | 69 ++++-------- australasia | 46 +++----- backward | 288 +++++++++++++++++++++++++++++++++++++++---------- checklinks.awk | 17 +++ etcetera | 17 ++- europe | 202 ++++++++++++---------------------- northamerica | 86 ++++----------- southamerica | 15 --- theory.html | 1 + zdump.c | 4 +- ziguard.awk | 14 +++ 15 files changed, 472 insertions(+), 525 deletions(-) -- 2.37.3

2 8

Re: [tz] Northern Ontario (Canada)
by dpatte Oct. 17, 2022

Oct. 17, 2022

Individual reserves usually have their own names such as the one near Fort Frances, "Nigigoonsiminikaaning" (Little Otters Playing). If the whole treaty area followed a rule than I agree that the treaty name would be a good solution. ----- Original Message ----- From: Brian Inglis via tz [mailto:tz@iana.org] To: <tz(a)iana.org> Sent: Sat, 15 Oct 2022 17:35:27 -0600 Subject: Re: [tz] Northern Ontario (Canada) Hi folks, Given that ids are named for the largest municipality observing given rules, and those named municipalities are not documented as nor likely to have diverged from provincial rules, then applying those ids to rural areas, especially reserves, would be erroneous. In the case of Canadian rural reserves, large areas are normally covered by the federal treaties under which those settlements were negotiated, and if reserves in those treaty areas could be documented to have ignored DST, then perhaps better ids would be e.g. Treaty3 for the ON Lake of the Woods Area, and Treaty60 for the ON Nipigon Lake area, given that other applicable labels are likely to be either confusing, excessively long, or require uncommon fonts to render? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry On 2022-10-15 17:02, Chris Walton via tz wrote: > Paul, > The changes look correct except that you linked *America/Rainy_River* to > *America/Toronto* instead of *America/Winnipeg*. > Rainy River is west of 90°W and needs to remain on Central Time. > > David, > I don't deny that there may have been some small reserves that did not observe > daylight saving. > They could still be added to the database if somebody wants to do the research > and provide appropriate names. > However, it would be wrong to use the names of existing towns and cities to > represent small reserves that exist outside of those towns and cities. > > -chris > > On Sat, 15 Oct 2022 at 17:11, dpatte <dpatte(a)relativedata.com > <mailto:dpatte@relativedata.com>> wrote: > > My concern about these changes is that I seem to remember that some first > nations in those areas did not use daylight-savings time on their reserves, > and that they were real but very small 'zones', not the large zones they > ended up being assumed to be. > > Unfortunately I have no documentation either way on this. > > > *----- Original Message -----* > *From:* Paul Eggert via tz [mailto:tz@iana.org] <mailto:tz@iana.org> > *To:* "Chris Walton" <crj.walton(a)gmail.com <mailto:crj.walton@gmail.com>> > *Cc:* tz(a)iana.org <mailto:tz@iana.org> > *Sent:* Sat, 15 Oct 2022 12:53:28 -0700 > *Subject:* Re: [tz] Northern Ontario (Canada) > > Thank you for doing that investigative work. Proposed patch attached and > installed into the tzdb development repository on GitHub. > > This patch follows your suggestions, except that it moves Nipigon's and > Rainy River's dubious data to 'backzone' instead of removing them > entirely, as I worry that some users will want the appearance of > completeness no matter how illusory.

2 1

Re: [tz] Northern Ontario (Canada)
by dpatte Oct. 16, 2022

Oct. 16, 2022

My concern about these changes is that I seem to remember that some first nations in those areas did not use daylight-savings time on their reserves, and that they were real but very small 'zones', not the large zones they ended up being assumed to be. Unfortunately I have no documentation either way on this. ----- Original Message ----- From: Paul Eggert via tz [mailto:tz@iana.org] To: "Chris Walton" <crj.walton(a)gmail.com> Cc: tz(a)iana.org Sent: Sat, 15 Oct 2022 12:53:28 -0700 Subject: Re: [tz] Northern Ontario (Canada) Thank you for doing that investigative work. Proposed patch attached and installed into the tzdb development repository on GitHub. This patch follows your suggestions, except that it moves Nipigon's and Rainy River's dubious data to 'backzone' instead of removing them entirely, as I worry that some users will want the appearance of completeness no matter how illusory.

4 3

Northern Ontario (Canada)
by Chris Walton Oct. 15, 2022

Oct. 15, 2022

On January 1, 1970, the twin cities of Fort William and Port Arthur were merged to form the City of Thunder Bay. The TZ database currently shows that Thunder Bay has observed daylight saving every year from 1970 onwards with the exception of 1973. Back in July I raised some doubts on this mailing list about the 1973 data. I now have more proof that it is wrong. Somebody from the Thunder Bay Public Library was kind enough to send me two newspaper scans from 1973. Both scans are from the Chronicle Journal which has been a local Thunder Bay newspaper since 1972. *Chronicle Journal - Saturday April 28, 1973 - page 1* This page contains a slightly corny but very relevant notice titled "*Clocks Move Ahead Sunday*''. It reads: > Advancing an hour glass one hour for daylight saving time appears to pose > a problem for Pat Plachta. She knows DST begins at 2 a.m. Sunday and she'll > have one less hour to sleep in the morning but she'll make it up in the > Fall. Above the article is a picture of a woman holding an hourglass. Being that this is a Thunder Bay newspaper, the implication is that Thunder Bay did observe daylight saving in 1973. For completeness, I will also mention that the same newspaper page also contains a generic Canadian Press article titled "*Canadians Will Lose Hour Sleep*". The article briefly documents daylight saving practices across the country with no mention of any specific towns or cities. It starts out with: > OTTAWA (CP) — 12:01 a.m. becomes 1:01 a.m. in Canada Sunday. ... Clearly that first line is not entirely correct because most (but not all) of Canada was doing the switch at 2:00a.m. instead of 12:01a.m. I am not quoting the entire article here because it is not specific to Thunder Bay and there is nothing in it that we do not already know. *Chronicle Journal - Saturday October 27, 1973 - page 1* This page contains a notice titled "*Extra Sleep*". It reads: > Tonight city residents can look forward to gaining an extra hour of rest, > as Thunder Bay goes from Daylight Saving Time to Eastern Standard Time. So > don't forget to set your clocks back an hour tonight at 12:01 a.m. I will assume that 12:01 is an error; since most cities and towns in Ontario switched at 2:00a.m. Regardless, the notice provides additional proof that Thunder Bay did observe daylight saving in 1973. The TZ database entry for *America/Thunder_Bay* should be updated to include the observance of daylight saving in 1973. This change will make *America/Thunder_Bay* identical to *America/Toronto* from October 26, 1969 until present. Ultimately, *America/Thunder_Bay *could be replaced with a link. It could also be maintained in the backzone file using pre-1970 history from either Port Arthur or Fort William. Both Port Arthur and Fort William started their first experiments with daylight saving on May 2, 1908 which is not currently reflected in the *America/Thunder_Bay* data. Unfortunately I do not have a complete history for Port Arthur or Fort William however there are a couple of sources to start with: https://www.thunderbay.ca/en/inc/blog.aspx (scroll to the bottom) http://www.bayviewmagazine.com/article/2022/03/great-springing-forward-deba… Also, I would also like to see *America/Nipigon *and* America/Rainy_River* converted into link entries because I have zero faith in the current Shanks based data. America/Nipigon --> America/Toronto America/Rainy_River --> America/Winnipeg I am not convinced it is worth saving the data for either of these two questionable zones inside the backzone file. As I pointed out in July, the TZ database shows that Nipigon started daylight saving in 1974, but newspaper evidence shows it was already using daylight saving at least as far back as 1972. https://news.ourontario.ca/npl/122271/page/2 And FYI: The *America/Nipigon* and *America/Rainy_River* boundaries were removed from OpenStreetMap back in August. The *America/Toronto* boundary was restored to include most of Ontario east of 90°W. I was happy to see it done. -chris

2 1

time keeps on slipping into the future
by Bradley White Oct. 15, 2022

Oct. 15, 2022

tzfile.5 says: > After the second header and data comes a newline-enclosed, > POSIX-TZ-environment-variable-style string for use in handling > instants after the last transition time stored in the file I had imagined that the reference implementation would apply the future rule for all of the future, but I currently observe that UTC-offset changes get stuck after a while for many (but not all) zones. For example, for *"Australia/Sydney"*, whose POSIX TZ string is *"AEST-10AEDT,M10.1.0,M4.1.0/3"*, tz_localtime_rz() produces the following civil times at the given instants: 14745254399 = 2437-04-05T02:59:59+1100 14745254400 = 2437-04-05T02:00:00+1000 14760979199 = 2437-10-04T01:59:59+1000 14760979200 = 2437-10-04T03:00:00+1100 That looks good ... daylight time from the first Sunday in Oct through the first Sunday in Apr, shifting at 03:00. But once we hit 2438, the UTC offset is stuck at +1100. For example, in July we would expect to see standard time, but instead get: 14784296400 = 2438-07-01T00:00:00+1100 And it never seems to recover after that. I'm pretty sure this used to work.

2 8