- tz - lists.iana.org

Leap year bugs
by Matt Johnson-Pint Jan. 24, 2020

Jan. 24, 2020

Hello Time People! Apologies in advance, as I know this is a bit off-topic being not about time zones, but I know that many of you are invested in date and time programming, and I'd appreciate some peer discussion. I've been invested in the last many months on preventative measures against leap year bugs, both in my day job at Microsoft and in the public space. Some of my recent posts: https://stackoverflow.com/questions/57530882/what-are-some-examples-of-leap… https://codeofmatt.com/on-the-life-cycle-of-a-leap-year-bug/ And from last leap year: https://codeofmatt.com/list-of-2016-leap-day-bugs/ https://azure.microsoft.com/en-us/blog/is-your-code-ready-for-the-leap-year/ Sometimes I feel like I'm overreacting, but then I remember the infamous 2012 Azure cloud leap day outage, and all the many other things across the industry that were impacted in 2016 (see my list above). My question for the community is this: Why are Y2K and Y2038 bugs such a hot topic when they are/were one-time events, but yet leap year bugs are rarely discussed even though they are recurring and can have critical impact? People seem to remember 20 years ago, but not 4 or 8 years back. Why? Are any of you working on leap year related issues? Have you checked your date math for leap year bugs? If not, why? Thanks, Matt

5 10

Re: [tz] Leap year bugs
by Hal Murray Jan. 24, 2020

Jan. 24, 2020

> [really hassles of being born on the leap day!] Many years ago, I got a "Congratulations for 10 years service" type certificate from a large corporation. It was dated Feb 29th. -- These are my opinions. I hate spam.

1 0

[PATCH] Cite Frumer on pre-1873 Japan timekeeping
by Paul Eggert Jan. 19, 2020

Jan. 19, 2020

* asia: Add a comment on timekeeping in Japan from the 7th to the 19th century. --- asia | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/asia b/asia index 590c05b..11a1726 100644 --- a/asia +++ b/asia @@ -1828,6 +1828,16 @@ Zone Asia/Jerusalem 2:20:54 - LMT 1880 # '9:00' and 'JST' is from Guy Harris. +# From Paul Eggert (2020-01-19): +# Starting in the 7th century, Japan generally followed an ancient Chinese +# timekeeping system that divided night and day into six hours each, +# with hour length depending on season. In 1873 the government +# started requiring the use of a Western style 24-hour clock. See: +# Yulia Frumer, "Making Time: Astronomical Time Measurement in Tokugawa Japan" +# <https://www.worldcat.org/oclc/1043907065>. As the tzdb code and +# data support only 24-hour clocks, its tables model timestamps before +# 1873 using Western-style local mean time. + # From Hideyuki Suzuki (1998-11-09): # 'Tokyo' usually stands for the former location of Tokyo Astronomical # Observatory: 139° 44' 40.90" E (9h 18m 58.727s), 35° 39' 16.0" N. -- 2.24.1

1 0

New leapseconds.awk doesn't work on macOS
by Chris Woodbury Jan. 17, 2020

Jan. 17, 2020

"leapseconds.awk" no longer has a CRLF problem per se. That is, just as long as we don't do something silly like printing strings with CRs in them (which we used to do but don't do now). At the time I reported the CRLF problem on 2019-07-27 at 05:47:10 UTC, leapseconds.awk was still using the comments as data to print the date of the zic "leap" directives it generates. (https://mm.icann.org/pipermail/tz/2019-July/028382.html) We don't do that anymore. The actual NTP timestamp datum is now being used to create the necessary date string thanks to Dr. Eggert's implementation of Dennis C. Ferguson's sstamp_to_ymdhMs() AWK function. (https://mm.icann.org/pipermail/tz/2019-September/028495.html) The two remaining string variables we use with CRs in them, the update and expiry NTP timestamps, are processed arithmetically before their values are printed. This eliminates the CRs as an issue with them. I still think it would be a good idea to use int() or strtonum() when they are read because the CRs *are* there. There are no leading zeroes to preserve (which was the primary objection I heard for not using int()). (https://blog.longnow.org/02013/12/31/long-now-years-five-digit-dates-and-10…) (Seven thousand nine hundred and eighty years from now...? This is farther in the future than the discovery of agriculture is in the past...) The sub() on $0 is unnecessary (and possibly bad practice). (I could argue on either side of the issue.) $ git diff leapseconds.awk diff --git a/leapseconds.awk b/leapseconds.awk index 924ade9..0e3eb1a 100755 --- a/leapseconds.awk +++ b/leapseconds.awk @@ -71,15 +71,13 @@ BEGIN { sstamp_init() } -# In case the input has CRLF form a la NIST. -{ sub(/\r$/, "") } - /^#[ \t]*[Uu]pdated through/ || /^#[ \t]*[Ff]ile expires on/ { last_lines = last_lines $0 "\n" } -/^#[$][ \t]/ { updated = $2 } -/^#[@][ \t]/ { expires = $2 } +# In case the input has CRLF form a la NIST. +/^#[$][ \t]/ { updated = int( $2 ) } +/^#[@][ \t]/ { expires = int( $2 ) } /^[ \t]*#/ { next }

2 1

[PROPOSED 1/3] Fix leap second bug after last explicit transition
by Paul Eggert Jan. 15, 2020

Jan. 15, 2020

The client code mishandled timestamps after the last explicit transition in a TZif file that had both leap seconds and daylight saving time transitions projected into the indefinite future. When interpreting the TZ string embedded at the end of the TZif file, the code neglected to adjust the corresponding DST transitions for leap seconds, which meant the DST transitions were calculated to occur too early. For example, with TZ set to '.../zoneinfo-leaps/America/Los_Angeles', zdump reported a DST transition on 2038-03-14 from 01:59:32.999... to 02:59:33 instead of the correct transition from 01:59:59.999... to 03:00:00. * NEWS: Mention this. * localtime.c (tzloadbody): Apply leap second corrections to transitions derived from the trailing TZ string in a TZif file. (leapcorr) [!STD_INSPIRED]: Define in this case too, since tzloadbody now uses it. --- NEWS | 8 ++++++++ localtime.c | 35 +++++++++++++++++++---------------- 2 files changed, 27 insertions(+), 16 deletions(-) diff --git a/NEWS b/NEWS index 961aa08..72e5c04 100644 --- a/NEWS +++ b/NEWS @@ -13,6 +13,14 @@ Unreleased, experimental changes Changes to code + localtime.c no longer mishandles timestamps after the last + transition in a TZif file with leap seconds and with daylight + saving time transitions projected into the indefinite future. + For example, with TZ='America/Los_Angeles' with leap seconds, + zdump formerly reported a DST transition on 2038-03-14 + from 01:59:32.999... to 02:59:33 instead of the correct transition + from 01:59:59.999... to 03:00:00. + The configuration macros HAVE_TZNAME and USG_COMPAT should now be set to 1 if the system library supports the feature, and 2 if not. As before, these macros are nonzero if tzcode should support the diff --git a/localtime.c b/localtime.c index d3f8fc7..6623eac 100644 --- a/localtime.c +++ b/localtime.c @@ -158,6 +158,7 @@ static struct tm *gmtsub(struct state const *, time_t const *, int_fast32_t, struct tm *); static bool increment_overflow(int *, int); static bool increment_overflow_time(time_t *, int_fast32_t); +static int_fast64_t leapcorr(struct state const *, time_t); static bool normalize_overflow32(int_fast32_t *, int *, int); static struct tm *timesub(time_t const *, int_fast32_t, struct state const *, struct tm *); @@ -641,11 +642,13 @@ tzloadbody(char const *name, struct state *sp, bool doextend, for (i = 0; i < ts->timecnt; i++) if (sp->timecnt == 0 - || sp->ats[sp->timecnt - 1] < ts->ats[i]) + || (sp->ats[sp->timecnt - 1] + < ts->ats[i] + leapcorr(sp, ts->ats[i]))) break; while (i < ts->timecnt && sp->timecnt < TZ_MAX_TIMES) { - sp->ats[sp->timecnt] = ts->ats[i]; + sp->ats[sp->timecnt] + = ts->ats[i] + leapcorr(sp, ts->ats[i]); sp->types[sp->timecnt] = (sp->typecnt + ts->types[i]); sp->timecnt++; @@ -2239,20 +2242,6 @@ timeoff(struct tm *tmp, long offset) #endif /* defined STD_INSPIRED */ -/* -** XXX--is the below the right way to conditionalize?? -*/ - -#ifdef STD_INSPIRED - -/* -** IEEE Std 1003.1 (POSIX) says that 536457599 -** shall correspond to "Wed Dec 31 23:59:59 UTC 1986", which -** is not the case if we are accounting for leap seconds. -** So, we provide the following conversion routines for use -** when exchanging timestamps with POSIX conforming systems. -*/ - static int_fast64_t leapcorr(struct state const *sp, time_t t) { @@ -2268,6 +2257,20 @@ leapcorr(struct state const *sp, time_t t) return 0; } +/* +** XXX--is the below the right way to conditionalize?? +*/ + +#ifdef STD_INSPIRED + +/* +** IEEE Std 1003.1 (POSIX) says that 536457599 +** shall correspond to "Wed Dec 31 23:59:59 UTC 1986", which +** is not the case if we are accounting for leap seconds. +** So, we provide the following conversion routines for use +** when exchanging timestamps with POSIX conforming systems. +*/ + NETBSD_INSPIRED_EXTERN time_t time2posix_z(struct state *sp, time_t t) { -- 2.24.1

3 7

Y2K quick-fix crick? Y2K20 bitten by 1970 + 50 year wrap
by Brian Inglis Jan. 15, 2020

Jan. 15, 2020

https://www.theregister.co.uk/2020/01/13/y2k_dvla/ https://gothamist.com/news/y2k20-parking-meter-software-glitch-causes-cityw… https://www.freightwaves.com/news/trimble-requests-extension-to-fmcsa-repai… -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.

1 0

Re: [tz] Leap Second Support Interval Field Request - RFC8536
by Paul Eggert Jan. 15, 2020

Jan. 15, 2020

On 12/4/19 1:04 PM, Michael Veth wrote: > The NIST leapsecond bulletin includes an expiration time which serves to > indicate the maximum validity interval for use of UTC time. In order to > safely use UTC timestamps, the user needs to be aware of this maximum > validity time or they could be unknowingly introducing timing errors. > > I was not able to find this field in the TZif (Feb 19) ICD. Would it be > possible to add a field to the TZdb that would represent this expiration > time? The TZif file format does provide for truncated files (see Internet RFC 8536 section 5.1), and one can generate files truncated to the current UTC expiration time (2020-06-28 00:00:00 UTC) with a command like this: zic -r /@1593302427 -L leapseconds tzdata.zi However, it's awkward that one must count the number of seconds since 1970-01-01 00:00:00 UTC (including leap seconds) by hand to get the numeric timestamp (1593302427 in this case) to pass to zic. We could add support to zic to do this sort of thing in a more-natural way. A downside of the abovementioned approach is that it generates a TZif file that omits all DST and time zone transitions after the UTC expiration time. We could change the TZif format to represent UTC expiration time separately from the truncation time. One possibility would be to append a leap-second record with an "occur" value equal to the expiration time and a "corr" value equal to the previous record's "corr" value. Strictly speaking this would violate RFC 8536 section 3.2 "leap-second records" - though I doubt whether many clients would care - and so I suppose we'd need to increment the TZif format version number from 3 to 4. On the other hand, any files generated by this method would continue to be "incorrect" in that they'd continue to predict timestamps past the maximum leap second validity, so perhaps it wouldn't be worth going to all this work to generate "incorrect" files. I'll cc this to tz(a)iana.org and tzdist-bis(a)ietf.org to see whether anybody there cares to comment.

4 6

New leapseconds.awk doesn't work on macOS
by Deborah Goldsmith Jan. 11, 2020

Jan. 11, 2020

Hi, I just noticed that starting with 2019c, leapseconds.awk is producing a damaged leapseconds file on macOS, e.g.: > # All leap-seconds are Stationary (S) at the given UTC time. > # The correction (+ or -) is made at the given time, so in the unlikely > # event of a negative leap second, a line would look like this: > # Leap YEAR MON DAY 23:59:59 - S > # Typical lines look like this: > # Leap YEAR MON DAY 23:59:60 + S > > # POSIX timestamps for the data in this file: > #updated -2208988800 (1900-01-01 00:00:00 UTC) > #expires -2208988800 (1900-01-01 00:00:00 UTC) > It turns out that having a regex in RS is a gawk feature and is not supported in Darwin awk. Commenting out the definition of RS in leapseconds.awk fixed the problem. I don’t know how many customers of TZ will be using versions of awk that don’t support regexes in RS. I don’t know about FreeBSD, OpenBSD, etc. Thanks, Debbie

6 8

new NIST leap-seconds.list
by Chris Woodbury Jan. 10, 2020

Jan. 10, 2020

There is a new NIST leap-seconds.list (thanks to Dr. Judah Levine). diff --git a/leap-seconds.list b/leap-seconds.list index a1bc5a7..529dc4a 100644 --- a/leap-seconds.list +++ b/leap-seconds.list @@ -62,7 +62,7 @@ # Terry Quinn, "The BIPM and the Accurate Measurement # of Time," Proc. of the IEEE, Vol. 79, pp. 894-905, # July, 1991. <http://dx.doi.org/10.1109/5.84965> -# reprinted in: +# reprinted in: # Christine Hackman and Donald B Sullivan (eds.) # Time and Frequency Measurement # American Association of Physics Teachers (1996) @@ -204,10 +204,10 @@ # current -- the update time stamp, the data and the name of the file # will not change. # -# Updated through IERS Bulletin C58 -# File expires on: 28 June 2020 +# Updated through IERS Bulletin C59 +# File expires on: 28 December 2020 # -#@ 3802291200 +#@ 3818102400 # 2272060800 10 # 1 Jan 1972 2287785600 11 # 1 Jul 1972 @@ -252,4 +252,4 @@ # the hash line is also ignored in the # computation. # -#h f28827d2 f263b6c3 ec0f19eb a3e0dbf0 97f3fa30 +#h a1c168ae 27c79a7d 9dddcfc3 bcfe616b 2e2c44ea \ No newline at end of file

2 1

new NIST leap-seconds.list
by Chris Woodbury Jan. 10, 2020

Jan. 10, 2020

> On Fri, 10 Jan 2020 13:57:17 -0500, John Hawkinson <jhawk(a)alum.mit.edu> wrote: > Has this diff been hand-edited? There does not appear to be a difference at line 65 (middle of the first hunk)? > Or maybe something was lost though a copy/paste to email? A space was lost in cut/paste (mi culpa). In line 65, the extra space ("Reprinted in: ") was eliminated by Dr. Levine. $ sed -n -e 65p a/leap-seconds.list | od -c 0000000 # \t \t r e p r i n t e d i n : 0000020 \n 0000022 $ sed -n -e 65p b/leap-seconds.list | od -c 0000000 # \t \t r e p r i n t e d i n : 0000020 \n 0000021

1 0

Request RE: academic research question re: TZ database
by Andrew Lyon Jan. 10, 2020

Jan. 10, 2020

Hello. I am a clinical biochemist and not well versed in handling the TZ database. I am investigating a software problem related to hospital patient data management that appears to be triggered when the software encounters a patient record with a date-of-birth that coincides with a historic daylight saving time Spring transition date. Through this investigation I have learned many details about the history of daylight saving time, but I often question the reliability of sources of information. It appears that many use the tz database as a source of truth. I am seeking assistance to query the tz database to determine the entries in the database for Area /Location America/Regina to determine the (1) daylight saving time Spring transition date and (2) daylight saving time Spring transition hour from 1900 to 1966. I understand there were 10 years between 1930 and 1941 when the hour of Spring daylight saving transition was 0000 (midnight) to 0100. I would like to confirm these entries are in the tz database. I have numerous references that daylight saving time was also observed in America/Regina during world war ONE ( 1914-1918) and I am uncertain if those entries are in the tz database or the hour of those transitions. I am uncertain if it is appropriate to ask for this type of assistance on this discussion group. Thank-you very much, regards, Andrew Dr. A.W. Lyon Dept Pathology and Laboratory Medicine University of Saskatchewan

6 10

Some inconsistency in times during the transitions between DST and non-DST times...
by Alan Lehotsky Jan. 9, 2020

Jan. 9, 2020

I’m supporting a “port” of the tz code where I’ve selectively embedded pieces of localtime.c into an application , so this may be something I’ve broken, but I’ve looked fairly carefully at my implementation. There seems to be a problem with the binary search to find the nearest transition times, when you are within the “fall-behind” transition. If I am in the Europe/London timezone and have a time like "2019-10-27 01:16:46” converting it to UTC is producing the same time (because it ends up finding the non-DST range. But ONE second earlier ends up thinking it’s within the DST range, so "2019-10-27 01:16:45” ends up reporting “2019-10-2 00:16:45” I tried to use the gnu date command to see if I could reproduce this in a clean tz environment using the -u -d flags, and couldn’t duplicate the problems I’m seeing, so there’s a possibility that this is something I’m doing wrong. But the following experimental change in localsub makes it consistently pick the non-dst representation of the time. } else { int lo = 1; int hi = sp->timecnt; while (lo < hi) { int mid = (lo + hi) >> 1; if (t < sp->ats[mid]) hi = mid; else lo = mid + 1; } i = (int) sp->types[lo - 1]; // Check if this is a dst setting AND 't' is within the magic hour that // replays when we fall behind. In this case we always treat a time as // not in the dst. // if (sp->ttis[i].tt_isdst && (t - sp->ttis[i].tt_gmtoff) > sp->ats[lo-1]) i = (int) sp->types[lo]; } ttisp = &sp->ttis[i]; Does this make any sense?

2 1

Updated Eggert leap-seconds.list
by Chris Woodbury Jan. 8, 2020

Jan. 8, 2020

On the occasion of a new IERS Bulletin C, I present an updated version of a public domain leap-second.list file. # -=*( This file is in the public domain )*=- # This NTP leap-second file was created with data obtained from # the United States Naval Observatory (USNO) MAIA FTP server. # # Find it at: <ftp://maia.usno.navy.mil/ser7/leapsec.dat> (down) # <ftp://cddis.gsfc.nasa.gov/pub/products/iers/leapsec.dat> (backup) # Updated using information from IERS Bulletin C 59 (7 Jan 2020) # Found at <ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat> # # IERS Bulletin C 59 did not announce a new leap-second. # # The last leap-second occurred on 1 Jan 2017 (3692217600) # which was announced in IERS Bulletin C 52 on 6 July 2016. # # -=<*>=- # # This file is not produced by a national metrology laboratory. # It *is* created using data from one: # # United States Naval Observatory (USNO) # IERS Rapid Service/Prediction Center for Earth Orientation # 3450 Massachusetts Ave NW, Washington, DC 20392 # # It should be noted that anyone with proper information can # generate an NTP leap-seconds.list file. # # The generation of this file was at the behest of Dr. Eggert # on the occasion of a US government shutdown which resulted # in a lack of an NIST generated file until late in January 2019. # # -=<*>=- # # The Network Time Protocol (NTP) keeps time in Coordinated # Universal Time (UTC). UTC is a time scale based upon # Standard International (SI) seconds and derived from Temps # Atomique International (TAI). UTC is the de facto basis for # legal time for much of the world since 1 Jan 1972 0h. # # [Le] Bureau International des Poids et Mesures (BIPM) tracks # TAI, UT1, TE, UTC, etc. uses a weighted ensemble of 420+ atomic # clocks at over 80+ national metrology laboratories worldwide # to track time and Very-Long-Baseline Interferometry (VLBI) # for precision millisecond pulsars timing and to track Earth's # orientation in space. The origin of TAI has been agreed # officially to coincide with UT1 on 1 January 1958 0h. # # For further information, read BIPM monograph "Time Scales" # found at: # # <https://www.bipm.org/... # utils/common/pdf/monographies-misc/Monographie1994-1.pdf> # # And "Coordinated Universal Time" at: # # <https://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-32_noteUTC.pdf> # # And, lastly: # # "Atomic Time Scales for Dynamical Astronomy" pp.51-56 # # "How Can Millisecond Pulsars Improve the Long-Term Stability # of Atomic Time Scales?", pp.57-60: # # Proceedings of the 6th European Frequency and Time Forum # (17-19 March 1992) # # <http://www.eftf.org/proceedings/proceedingsEFTF1992.pdf> # # -=<*>=- # # Leap seconds are an official correction to UTC to keep it # within 0.9 seconds of UT1; yet another time standard # based upon the orientation of the earth in space (and the # basis of legal time until 1972). IERS Bulletin A keeps # track of and predicts the value of UT1-UTC. # # See: ftp://maia.usno.navy.mil/ser7/ser7.dat (down) # ftp://cddis.gsfc.nasa.gov/pub/products/iers/ser7.dat (backup) # # The data kept in "leap-seconds.list" are used by the # Network Time Protocol daemon (NTPd) to determine when to # apply leap seconds to Coordinated Universal Time (UTC). # "leap-seconds.list" is a symbolic link to the actual # file name, leap-seconds.xxxxxxxxxx, where xxxxxxxxxx # is derived from the NTP update timestamp (below). # # Theoretically, a leap second may be positive or negative. # Realistically, negative leap seconds are unlikely to occur. # # All timestamps in this leap seconds file are encoded using the # NTP epoch. These timestamps represent the number of seconds # since 1 Jan 1900 0:00:00. This is Modified Julian Date (MJD) # 15020 and Julian Date 2415020.5. There will be an unsigned # 32-bit overflow to the second NTP era in 2036 (07 Feb 2036 # 06:28:16 UTC to be precise). # # A leap second datum consists of an NTP timestamp and the # number of seconds difference between TAI and UTC (e.g. # currently TAI-UTC is 37). UTC was established (at # midnight) on 1 Jan 1972 0h with TAI-UTC started at 10. # There was no mechanism prior to that time defining when # to apply leap seconds. # # Note: the first datum in the leap-seconds.list file is # *not* a leap-second; it denotes the definition of the # UTC timescale. # # Leap-seconds rules are establish in: # # International Telecommunications Union-Recommendation (ITU-R) # 460-6 (Standard-frequency and Time-Signal Emissions), # Annex 1 (Time scales), Section 2 (Leap-Seconds). # # Note: Version 460-6 of the Recommendation is incorporated # by reference in the [ITU] Radio Regulations. # # <http://www.itu.int/rec/R-REC-TF.460-6-200202-I/> # # Also note that Annex 1, Section 2.1 of this document contradicts # the comments in Bulletin C regarding as to when a leap-second # may be applied. i.e. As the last second of any UTC month. # Preference is given to June and December and, secondarily, in # March and September. (All have been in June or December.) # # Section 2.3: Delegates leap-second timing/dissemination to the # International Earth Rotation and Reference System Service (IERS), # (in its role as inheritor of Bureau International de l'Heure (BIH)). # # NTP Leap second files have an update time (#$). This is often # the UTC zero (0) hour time of the day when the leap second file # is built. [I am of the opinion] it should be updated whenever # a new IERS Bulletin C is issued. CCW] # #$ 3787382231 # # Leap second data have a lifetime. Traditionally, this ends on # the twenty-eighth (28) day of the month six months after the # period of time described in the latest IERS Bulletin C. This # is the expiry time (#@). # # Updated through IERS Bulletin C 59 (7 Jan 2020) # File expires on: 28 Jul 2020 # #@ 3818102400 # # Leap second files have a hash, as define in NIST's FIPS 180 # Secure Hash Standard (SHS), current revision 4 (FIPS 180-4). # # FIPS Publications: <http://csrc.nist.gov/publications/fips/> # Direct Link: <http://dx.doi.org/10.6028/NIST.FIPS.180-4> # # It is based on an SHA[1] digest, created using the data # portions of the file including leap second data and the update # and expiry timestamps. All "white space" and comments are # ignored in the computation thereof. The 160-bit SHA[1] # digest polynomial are encoded in five hexadecimal grouping at # the end of the file (#h). The hash itself is NOT included in # the SHA[1]. It can also be calculated using GNU sha1sum which # generates the same 160-bit digest, given the same data, in # forty hexadecimal characters. # # NTP delta #timestamp T Date of Change # 2272060800 10 # 1 Jan 1972 (MJD 41317) 2287785600 11 # 1 Jul 1972 (MJD 41499) 2303683200 12 # 1 Jan 1973 (MJD 41683) 2335219200 13 # 1 Jan 1974 (MJD 42048) 2366755200 14 # 1 Jan 1975 (MJD 42413) 2398291200 15 # 1 Jan 1976 (MJD 42778) 2429913600 16 # 1 Jan 1977 (MJD 43144) 2461449600 17 # 1 Jan 1978 (MJD 43509) 2492985600 18 # 1 Jan 1979 (MJD 43874) 2524521600 19 # 1 Jan 1980 (MJD 44239) 2571782400 20 # 1 Jul 1981 (MJD 44786) 2603318400 21 # 1 Jul 1982 (MJD 45151) 2634854400 22 # 1 Jul 1983 (MJD 45516) 2698012800 23 # 1 Jul 1985 (MJD 46247) 2776982400 24 # 1 Jan 1988 (MJD 47161) 2840140800 25 # 1 Jan 1990 (MJD 47892) 2871676800 26 # 1 Jan 1991 (MJD 48257) 2918937600 27 # 1 Jul 1992 (MJD 48804) 2950473600 28 # 1 Jul 1993 (MJD 49169) 2982009600 29 # 1 Jul 1994 (MJD 49534) 3029443200 30 # 1 Jan 1996 (MJD 50083) 3076704000 31 # 1 Jul 1997 (MJD 50630) 3124137600 32 # 1 Jan 1999 (MJD 51179) 3345062400 33 # 1 Jan 2006 (MJD 53736) 3439756800 34 # 1 Jan 2009 (MJD 54832) 3550089600 35 # 1 Jul 2012 (MJD 56109) 3644697600 36 # 1 Jul 2015 (MJD 57204) 3692217600 37 # 1 Jan 2017 (MJD 57754) # #h 85073416 421bdd85 47662775 e154160c 4f1a3070

1 0

Bulletin C 59
by Chris Woodbury Jan. 8, 2020

Jan. 8, 2020

Phoo, my pasteinig into my e-mail program munged the URL of where to find the IERS Bulletin A at NASA's Goldstone Space Flight Center. It's: ftp://cddis.gsfc.nasa.gov/pub/products/iers/ser7.dat

2 1

Bulletin C 59
by Chris Woodbury Jan. 7, 2020

Jan. 7, 2020

> Steve Allen sla at ucolick.org wrote on Tue Jan 7 20:15:38 UTC 2020 > In the middle of last year the Earth's crust accelerated such that we > were rotating faster than 200 years ago. The value of Delta T > decreased during a few weeks. The Length of Day (LoD), as Dr. Allen knows better than I, is effected by many factors. Having picked a length for the atomic SI second where 86,400 of them add up to a day shorter than the mean Solar day by milliseconds, we have been playing "catch up" since UTC was defined. The tides slowing down the crustal rotation, along with torque applied directly on the Earth oblate spheroid by Sol and other celestial bodies, along with other factors, change the rate at which the LoD changes. I have been fascinated by the fact that Bulletin A projections of UT1-UTC have put the point where it reaches -0.4 (which is typically when IERS inserts a leap-second) further and further into to future. Recently, every week, the MJD where it gets to -0.3 (currently at -0.29480 on 2021-01-01) gets a week farther away. It has been proposed that the latest oddities are caused by angular momentum being transferred from the Earth's rotating solid core to the liquid surround it, the semi-solid mantle and, finally, to the crust. Not something instantaneous by any means. My favorite thought on the matter involves wondering about conservation of angular momentum as megatons of ice, melting at altitude, unaffected by friction, flows down hill to (a rising) sea-level. Much of that ice is miles in the air.... lots of potential energy realized into actual rotation by a change of position. (Think of it as an spinning ice skater pulling in her/his arms.) Change of spin would be effected by closeness of the ice to the spin axis/poles as well as height of sea level at the equator. One more thing to worry about....

1 0

Hour 26? (was: Chaning time zone for Unix based tasks)
by Paul Gilmartin Jan. 7, 2020

Jan. 7, 2020

(cross-posting to tz and IBM-MAIN) Hi, TZData, On a Linux system, I see: 1043 $ uname -a Linux Bunsen5-PG 4.9.0-11-686-pae #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) i686 GNU/Linux 1044 $ cat /usr/share/zoneinfo/Asia/Tel_Aviv | tail -1 IST-2IDT,M3.4.4/26,M10.5.0 1045 $ ... This would seem to be Month 3, Week 4, Day 4, hour 26. 26? Is that supposed to be 02:00 the next day? But POSIX says: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#ta… ... The hour shall be between zero and 24, and the minutes (and seconds) -if present-between zero and 59. The result of using values outside of this range is unspecified. z/OS (which supports only POSIX format) seems to ignore that TZ (as allowed by "unspecified") and use UTC0: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r… (It doesn't specify.) Ouch! -- gil

3 4

Bulletin C 59
by Chris Woodbury Jan. 7, 2020

Jan. 7, 2020

Bulletin C 59 has been released on 2020-01-07 at 12:50:44 by IERS and there will be no leap-second in June 2020. There are also a new IERS leap-seconds list file (leap-seconds.3787382231) and Leap_Second.dat file (touched but unchanged). Visit ftp://hpiers.obspm.fr/iers/bul/bulc/ By all indications, there will be an unusually long interval before the next leap-second (July 2021 or later). See IERS Bulletin A at ftp://cddis.gsfc.nasa.gov/pub/products/iers/ser7.dat. (USNO's FTP sites are under construction.)

2 1

Fake UK news
by Lester Caine Dec. 31, 2019

Dec. 31, 2019

Or rather another proposal for changes to time zones that did not happen - SDST https://www.bbc.co.uk/news/uk-50950961 -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk

1 0

Timekeeping in the news
by Arthur David Olson Dec. 27, 2019

Dec. 27, 2019

"Boeing Starliner Ends Up In Wrong Orbit After Clock Problem." https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html @dashdashado

7 9

[PATCH] * asia: Correct Hong Kong section name.
by Jimmy Yuen Ho Wong Dec. 19, 2019

Dec. 19, 2019

There are no records of Hong Kong being referred to as Xianggang, in the past or currently. The Pinyin romanization scheme of the Mandarin pronunciation of 香港 is not officially recognized or even mentioned in official documents. https://www.basiclaw.gov.hk/en/basiclawtext/chapter_1.html https://www.elegislation.gov.hk/hk/cap5 --- asia | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/asia b/asia index cca004f..4f19d14 100644 --- a/asia +++ b/asia @@ -572,7 +572,7 @@ Zone Asia/Urumqi 5:50:20 - LMT 1928 6:00 - +06 -# Hong Kong (Xianggang) +# Hong Kong # Milne gives 7:36:41.7; round this. -- 2.24.0

2 1

[PATCH] * asia: Correct Hong Kong section name.
by Jimmy Yuen Ho Wong Dec. 18, 2019

Dec. 18, 2019

There are no records of Hong Kong being referred to as Xianggang, in the past or currently. The Pinyin romanization scheme of the Mandarin pronunciation of 香港 is not officially recognized or even mentioned in official documents. https://www.basiclaw.gov.hk/en/basiclawtext/chapter_1.html https://www.elegislation.gov.hk/hk/cap5 --- asia | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/asia b/asia index cca004f..4f19d14 100644 --- a/asia +++ b/asia @@ -572,7 +572,7 @@ Zone Asia/Urumqi 5:50:20 - LMT 1928 6:00 - +06 -# Hong Kong (Xianggang) +# Hong Kong # Milne gives 7:36:41.7; round this. -- 2.24.0

1 0

isdst bug Europe/Dublin (tzdb-2019c)
by Stefan Rueger Dec. 16, 2019

Dec. 16, 2019

Looks like zdump claims Dublin has DST during winter, not summer: $ ./zdump -i -c2020,2021 Europe/Dublin TZ="Europe/Dublin" - - +00 GMT 1 2020-03-29 02 +01 IST 2020-10-25 01 +00 GMT 1 Compare with the output for London, which is as I would expect: $ ./zdump -i -c2020,2021 Europe/London TZ="Europe/London" - - +00 GMT 2020-03-29 02 +01 BST 1 2020-10-25 01 +00 GMT Generally, I think it's neater if the time stretches with the larger GMT values are considered DST. This is almost always true, except for Europe/Dublin, Eire, Africa/Casablanca and Africa/El_Aaiun. Morocco (and Western Sahara) change the time to have shorter fasts during Ramadan, so to speak to *not* save daylight. I would therefore still argue that the time outside Ramadan should be considered DST and the time during Ramadan the non-DST time. I am aware that the view "DST means larger GMT value" is not a precise definition (a region that change times zones in quick succession might easily accrue more than two GMT values within a few years). It's therefore not a great candidate for implementation in zic/zdump. However, I hold that periodic *future* annual back-and-forth switches should adopt that principle. Anyway, over to you Stefan PS: You are providing an *amazing* service - many thanks for that!

11 37

(no subject)
by Misty HICKMAN Dec. 16, 2019

Dec. 16, 2019

Yes . MistY 18months now . Very clear you know. The cAlEndAr Y ear ? Remember the TeaCUp ..

1 0

Re: [tz] Anticipated strategy for handling US state DST rule changes
by Paul Eggert Dec. 12, 2019

Dec. 12, 2019

On 12/12/19 7:39 AM, David Braverman wrote: > Can we use America/New_York_State/Buffalo, for example? That would work, yes. But let's hope Buffalo stays aligned.

1 0

EU and Brexit Time Borders
by Brian Inglis Dec. 12, 2019

Dec. 12, 2019

EU member states get to decide whether to stay on summer or standard time: https://www.independent.ie/business/brexit/meps-vote-to-end-daylight-saving… What will Ireland do, and will Ulster follow Irish or UK time? https://www.independent.co.uk/news/uk/politics/brexit-irish-border-time-clo… Will UK follow, staying on GMT or BST, or keep switching? https://www.rospa.com/media/documents/road-safety/consultation-responses/di… "Under the new legislation, governments opting to make summer-time permanent would adjust their clocks for the last time on the last Sunday in March 2021. For those choosing permanent standard time, known as permanent winter-time, the final clock change would be on the last Sunday of October 2021." -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.

1 0