- tz - lists.iana.org

In the news: Russia wants to put illegally occupied regions to Moscow Time
by Derick Rethans Jan. 27, 2023

Jan. 27, 2023

Hi, saw this in the news: https://www.newsweek.com/russia-moscow-time-zone-ukraine-annexed-territorie… cheers, Derick

6 8

Dead PTB link
by Benjamin Drung Jan. 27, 2023

Jan. 27, 2023

Hi, I noticed that the PTB link http://www.ptb.de/de/org/4/44/441/salt.htm is dead. See attached patch (for git am) to update it to the current location. -- Benjamin Drung Debian & Ubuntu Developer

2 1

[PROPOSED 1/2] Update IDL commentary
by Paul Eggert Jan. 25, 2023

Jan. 25, 2023

--- australasia | 36 +++++++++++++++--------------------- 1 file changed, 15 insertions(+), 21 deletions(-) diff --git a/australasia b/australasia index 749b72c8..84d94b99 100644 --- a/australasia +++ b/australasia @@ -2199,24 +2199,18 @@ Zone Pacific/Efate 11:13:16 - LMT 1912 Jan 13 # Vila # an international standard, there are some places on the high seas where the # correct date is ambiguous. -# From Wikipedia <https://en.wikipedia.org/wiki/Time_zone> (2005-08-31): -# Before 1920, all ships kept local apparent time on the high seas by setting -# their clocks at night or at the morning sight so that, given the ship's -# speed and direction, it would be 12 o'clock when the Sun crossed the ship's -# meridian (12 o'clock = local apparent noon). During 1917, at the -# Anglo-French Conference on Time-keeping at Sea, it was recommended that all -# ships, both military and civilian, should adopt hourly standard time zones -# on the high seas. Whenever a ship was within the territorial waters of any -# nation it would use that nation's standard time. The captain was permitted -# to change his ship's clocks at a time of his choice following his ship's -# entry into another zone time - he often chose midnight. These zones were -# adopted by all major fleets between 1920 and 1925 but not by many -# independent merchant ships until World War II. - -# From Paul Eggert, using references suggested by Oscar van Vlijmen -# (2005-03-20): -# -# The American Practical Navigator (2002) -# http://pollux.nss.nima.mil/pubs/pubs_j_apn_sections.html?rid=187 -# talks only about the 180-degree meridian with respect to ships in -# international waters; it ignores the international date line. +# From Wikipedia <https://en.wikipedia.org/wiki/Nautical_time> (2023-01-23): +# The nautical time zone system is analogous to the terrestrial time zone +# system for use on high seas. Under the system time changes are required for +# changes of longitude in one-hour steps. The one-hour step corresponds to a +# time zone width of 15° longitude. The 15° gore that is offset from GMT or +# UT1 (not UTC) by twelve hours is bisected by the nautical date line into two +# 7°30' gores that differ from GMT by ±12 hours. A nautical date line is +# implied but not explicitly drawn on time zone maps. It follows the 180th +# meridian except where it is interrupted by territorial waters adjacent to +# land, forming gaps: it is a pole-to-pole dashed line. + +# From Paul Eggert (2023-01-23): +# The American Practical Navigator <https://msi.nga.mil/Publications/APN>, +# 2019 edition, merely says that the International Date Line +# "coincides with the 180th meridian over most of its length." -- 2.37.2

3 5

[PROPOSED 1/4] Allow “§” etc. in commentary
by Paul Eggert Jan. 24, 2023

Jan. 24, 2023

* Makefile (UNUSUAL_OK_LATIN_1): Allow all non-alphabetic, non-ASCII printable characters that are Latin-1. This is primarily for “§” and we might as well allow them all since even XEmacs 21 supports them all. --- Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 721a7452..17e3bb57 100644 --- a/Makefile +++ b/Makefile @@ -459,9 +459,10 @@ SAFE_CHARSET3= 'abcdefghijklmnopqrstuvwxyz{|}~' SAFE_CHARSET= $(SAFE_CHARSET1)$(SAFE_CHARSET2)$(SAFE_CHARSET3) SAFE_CHAR= '[]'$(SAFE_CHARSET)'-]' -# These characters are Latin-1, and so are likely to be displayable -# even in editors with limited character sets. -UNUSUAL_OK_LATIN_1 = «°±»½¾× +# These non-alphabetic, non-ASCII printable characters are Latin-1, +# and so are likely displayable even in editors like XEmacs 21 +# that have limited character sets. +UNUSUAL_OK_LATIN_1 = ¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿×÷ # This IPA symbol is represented in Unicode as the composition of # U+0075 and U+032F, and U+032F is not considered alphabetic by some # grep implementations that do not grok composition. -- 2.37.2

4 7

No leap second on 2023-06-30
by Tim Parenti Jan. 20, 2023

Jan. 20, 2023

Per IERS, Bulletin C 65 (2023-01-09) https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.65 …and forwarded below. A patch updating leap-seconds.list from NIST is attached, and is installed in the development repository. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Mon, 9 Jan 2023 at 05:36 Subject: Bulletin C number 65 To: <bulc.iers(a)obspm.fr> INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : +33 1 40 51 23 35 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 09 January 2023 Bulletin C 65 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of June 2023. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France

1 0

Maryland House Bill 165--permanent DST
by Arthur David Olson Jan. 19, 2023

Jan. 19, 2023

This year's session of the Maryland state legislature is off and running. On Monday, Delegate Crosby's bill 165 was read for the first time; it would put Maryland on permanent Daylight Saving Time. A similar bill was introduced last year; it passed the House but died in a Senate committee. The bill is contingent on federal enabling legislation and on adoption of permanent DST by neighboring jurisdictions. Once the contingencies are met, the bill specifies that "this Act shall take effect on the earlier of the second Sunday of March or the first Sunday of November." So yes, if the contingencies are met on October 31, there'd be less than a week's notice of cancellation of setting clocks back. I plan to be in touch with one of my representatives to suggest a parsimonious improvement: change "earlier" to "later." There are links to the bill's text and to a status page below. @dashdashado https://mgaleg.maryland.gov/2023rs/bills_noln/hb/fhb0165.pdf https://mgaleg.maryland.gov/mgawebsite/Legislation/Details/hb0165?ys=2023rs

1 0

not getting proper timezone for few countries
by Bhardwaj, vanshika Jan. 18, 2023

Jan. 18, 2023

Hello , We are using tzdata vendor source latest version which is 2022g in our code ,which basically return the timezones value of the country as per the mapping but we found for few of the countries we are getting alphanumeric value as an output of time-zone, like if we select India so timezones we are getting for India is IST as an output which is expected ,but if we select brasalia so timezones for Brasalia we are getting is -03 , which is alpha-numeric value , so can u please tell us when u are going to add the timezones for the rest of the countries or it will be same. Hope u will reply soon. With Regards, Vanshika Bhardwaj Associate Engineer(Eaton)

2 1

Swiss time selectable for Germany
by Benjamin Drung Jan. 17, 2023

Jan. 17, 2023

Hi, I tried tzselect for Germany and was presented with following question: Please select one of the following timezones. 1) Swiss time 2) Germany (most areas), Scandinavia We do not use Swiss time in Germany. I did some research: Germany switched to summertime in 1980 and Swiss in 1981. There is Büsingen am Hochrhein which followed Swiss and therefore deviated from Germany only in 1980. Should zone1970.tab reflect the current status (i.e. drop DE from Europe/Zurich and rename "Germany (most areas)" to "Germany" in the comments)? -- Benjamin Drung Debian & Ubuntu Developer

10 23

[PROPOSED] Be more consistent about MSK/MSD
by Paul Eggert Jan. 17, 2023

Jan. 17, 2023

* NEWS: Mention this. * europe (Europe/Volgograd, Europe/Kirov): Use the abbreviations MSK/MSD when using Moscow time, since that’s what other Russian timezones do. This fixes an inconsistency introduced in 2016g. --- NEWS | 6 ++++++ europe | 18 +++++++++--------- 2 files changed, 15 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 7bd80803..fc35046c 100644 --- a/NEWS +++ b/NEWS @@ -26,6 +26,12 @@ Unreleased, experimental changes since 1970. (Thanks to Almaz Mingaleev.) This affects some pre-1948 timestamps. The old data are now in 'backzone'. + Changes to past time zone abbreviations + + When observing Moscow time, Europe/Kirov and Europe/Volgograd now + use the abbreviations MSK/MSD instead of numeric abbreviations, + for consistency with other timezones observing Moscow time. + Changes to code You can now tell tzselect local time, to simplify later choices. diff --git a/europe b/europe index 89bc3a28..b784d0ee 100644 --- a/europe +++ b/europe @@ -2656,13 +2656,13 @@ Zone Europe/Volgograd 2:57:40 - LMT 1920 Jan 3 3:00 - +03 1930 Jun 21 4:00 - +04 1961 Nov 11 4:00 Russia +04/+05 1988 Mar 27 2:00s - 3:00 Russia +03/+04 1991 Mar 31 2:00s + 3:00 Russia MSK/MSD 1991 Mar 31 2:00s 4:00 - +04 1992 Mar 29 2:00s - 3:00 Russia +03/+04 2011 Mar 27 2:00s - 4:00 - +04 2014 Oct 26 2:00s - 3:00 - +03 2018 Oct 28 2:00s + 3:00 Russia MSK/MSD 2011 Mar 27 2:00s + 4:00 - MSK 2014 Oct 26 2:00s + 3:00 - MSK 2018 Oct 28 2:00s 4:00 - +04 2020 Dec 27 2:00s - 3:00 - +03 + 3:00 - MSK # From Paul Eggert (2016-11-11): # Europe/Saratov covers: @@ -2693,11 +2693,11 @@ Zone Europe/Saratov 3:04:18 - LMT 1919 Jul 1 0:00u Zone Europe/Kirov 3:18:48 - LMT 1919 Jul 1 0:00u 3:00 - +03 1930 Jun 21 4:00 Russia +04/+05 1989 Mar 26 2:00s - 3:00 Russia +03/+04 1991 Mar 31 2:00s + 3:00 Russia MSK/MSD 1991 Mar 31 2:00s 4:00 - +04 1992 Mar 29 2:00s - 3:00 Russia +03/+04 2011 Mar 27 2:00s - 4:00 - +04 2014 Oct 26 2:00s - 3:00 - +03 + 3:00 Russia MSK/MSD 2011 Mar 27 2:00s + 4:00 - MSK 2014 Oct 26 2:00s + 3:00 - MSK # From Tim Parenti (2014-07-03), per Oscar van Vlijmen (2001-08-25): # Europe/Samara covers... -- 2.37.2

1 0

localtime_r multiple times slower for Europe/Moscow timezone
by Benjamin Drung Jan. 11, 2023

Jan. 11, 2023

Hi, a Ubuntu user has been reporting in https://launchpad.net/bugs/868395 that the Europe/Moscow timezone is multiple times slower than other timezones. Here is the example bug.c code: ``` #include <time.h> #include <stdio.h> int main() { time_t t = time(0); int i; struct tm result; for(i=0; i < 10000000; i++) localtime_r(&t, &result); puts(ctime(&t)); return 0; } ``` Compile and run this code: ``` gcc -o bug bug.c time TZ=Etc/UTC ./bug time TZ=Europe/Berlin ./bug time TZ=Europe/Moscow ./bug ``` The result on my machine is that Etc/UTC, Europe/Berlin, and other timezones take around 250 to 400 ms, but Europe/Moscow takes 1200 ms. The result is the same when running in a Debian unstable, Ubuntu 22.04 (jammy) and Ubuntu 23.04 (lunar) chroot. Is that a bug? If yes, is that a bug in glibc? -- Benjamin Drung Debian & Ubuntu Developer

5 6

[PROPOSED 1/2] Fix stray ‘\’ in tzselect
by Paul Eggert Jan. 11, 2023

Jan. 11, 2023

* tzselect.ksh: Remove stray backslash that messed up the wording of a diagnostic. This glitch was introduced in commit 13980693084c36e0275828d8d46d9d9e8975be0d dated Wed Jun 27 11:24:09 2018 -0700. --- tzselect.ksh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzselect.ksh b/tzselect.ksh index 87baaa5..cbfc677 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -401,7 +401,7 @@ while BEGIN { FS = "\t" } { print $NF } '` - echo >&2 'Please select one of the following timezones,' \ + echo >&2 'Please select one of the following timezones,' echo >&2 'listed roughly in increasing order' \ "of distance from $coord". doselect $regions -- 2.39.0

1 1

[PROPOSED] Omit check_sorted dependencies no longer needed
by Paul Eggert Jan. 10, 2023

Jan. 10, 2023

* Makefile (check_sorted): Omit unnecessary dependencies on iso3166.tab, zone.tab, zone1970.tab. They should have been removed in commit 1bb4263bb1716fe3ba63b26600adc9c32f1fe16e dated 2019-06-22 13:55:46 -0700. --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 8bee50d..721a745 100644 --- a/Makefile +++ b/Makefile @@ -837,7 +837,7 @@ check_slashed_abbrs: $(TDATA_TO_CHECK) CHECK_CC_LIST = { n = split($$1,a,/,/); for (i=2; i<=n; i++) print a[1], a[i]; } -check_sorted: backward backzone iso3166.tab zone.tab zone1970.tab +check_sorted: backward backzone $(AWK) '/^Link/ {printf "%.5d %s\n", g, $$3} !/./ {g++}' \ backward | LC_ALL=C sort -cu $(AWK) '/^Zone/ {print $$2}' backzone | LC_ALL=C sort -cu -- 2.39.0

1 0

(no subject)
by Alfred Finamore Jan. 10, 2023

Jan. 10, 2023

Request

1 0

Re: [tz] tz Digest, Vol 136, Issue 11
by nadir altinbas Jan. 8, 2023

Jan. 8, 2023

There are 195 countries in the world today.As mentioned in ( https://www.worldometers.info/geography/how-many-countries-are-there-in-the…) About Today's Topics:. T?rkiye (Jonathan Leffler); My own comment is to be written as" Republic of Turkiye (Turkiye) " Thank Nadir Altinbas e:nadiraltinbas@yahoo.com n.altinbas On Sunday, January 8, 2023 at 03:00:07 PM GMT+3, tz-request(a)iana.org <tz-request(a)iana.org> wrote: Send tz mailing list submissions to tz(a)iana.org To subscribe or unsubscribe via the World Wide Web, visit https://mm.icann.org/mailman/listinfo/tz 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..." Today's Topics: 1. T?rkiye (Jonathan Leffler) ---------------------------------------------------------------------- Message: 1 Date: Sat, 7 Jan 2023 21:47:15 -0700 From: Jonathan Leffler <jonathan.leffler(a)gmail.com> To: Time Zone Mailing List <tz(a)iana.org> Subject: [tz] T?rkiye Message-ID: <CAH+RLGEKNgZK4c9e4rdO6nmU-tMHnZ3+cXMV9=6LVaJ7VvDAJg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" >From the Los Angeles Times, 2023-01-05 (summary from an email dated 2023-01-06): Ceding to a longstanding Turkish demand, the State Department on Thursday > agreed to begin spelling the country?s name in Turkish > <https://click.email.latimes.com/?qs=fff6b852d8f4b17927eabd337816fdb1705edee…> in > its official documents. Turkey will now be referred to as ?T?rkiye,? > Wilkinson reported. https://www.latimes.com/politics/story/2023-01-05/state-department-will-now… -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

1 0

Türkiye
by Jonathan Leffler Jan. 8, 2023

Jan. 8, 2023

>From the Los Angeles Times, 2023-01-05 (summary from an email dated 2023-01-06): Ceding to a longstanding Turkish demand, the State Department on Thursday > agreed to begin spelling the country’s name in Turkish > <https://click.email.latimes.com/?qs=fff6b852d8f4b17927eabd337816fdb1705edee…> in > its official documents. Turkey will now be referred to as “Türkiye,” > Wilkinson reported. https://www.latimes.com/politics/story/2023-01-05/state-department-will-now… -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

1 0

Re: [tz] ptrdiff_t changes in tzcode
by Paul Eggert Jan. 7, 2023

Jan. 7, 2023

On 2022-12-12 08:12, Christos Zoulas wrote: > How about changing it then to be: > > sum <= (ptrdiff_t)min(PTRDIFF_MAX, SIZE_MAX) > > This does the check explicitly and avoids the signed/unsigned warning? It is also what the #else part of the code does... This pattern > lives in many places, so we could put the RHS of the expression to a #define? Sure, we can do that. The attached proposed patch (installed in the development repository) uses a new macro INDEX_MAX to capture this notion. This shouldn't change behavior (or even generated code) but can help clarify things. (Although I'm not a fan of casts I don't see how to avoid it here.) >>> There are also a bunch of places now where you get sign comparison warnings (where ptrdiff_t is compared to size_t, like sizeof() or >>> the result of strlen(3). That's OK, they're false alarms: GCC and Clang go overboard in this department. To pacify the compilers you can compile with -Wno-sign-compare as suggested in Makefile's GCC_DEBUG_FLAGS macro. > I think that the ptrdiff_t changes make things more complicated... Yes, it's a tradeoff between complexity now, and simplicity/safety in the long run. Once we can assume C23 (say, 30 years from now!) we can get rid of the trickier code that ports to C17 and earlier. In the meantime as C23 becomes more popular we can start using the simpler code. (I did resist the temptation in the tricky code to write "itemsize**nitems_alloc", which though correct doesn't mean what it looks like....) >> By the way, I'd been meaning to try to sync tzdb localtime.c with NetBSD's at some point. Shouldn't be that hard, I'd think, and might help get bugs fixed faster (in both directions). > > That would be great! OK, thanks, I'll add that to my list of things to do.

6 14

Split America into North America and South America
by Benjamin Drung Jan. 7, 2023

Jan. 7, 2023

Hi, debconf [1] for the tzdata Debian/Ubuntu package ask for the geographic area (e.g. Europe, Asia, etc) and then for the city inside this area. The resulting timezone is $area/$city. While working on the debconf template, I noticed that the America directory is the biggest with 157 cities. Having to find the correct city in that big list can take some time. The second biggest area is Asia with 90 countries. The timezones are split by continent/ocean. The Afro-Eurasia continent is split into Africa, Asia, Europe, but America is not split into North America and South America. For consistency I suggest to split America into North America and South America to have all seven continents present [2]. The git repository already separate northamerica and southamerica files. [1] https://en.wikipedia.org/wiki/Debian_configuration_system [2] https://en.wikipedia.org/wiki/Continent -- Benjamin Drung Debian & Ubuntu Developer

7 8

Re: [tz] Split America into North America and South America
by dpatte Jan. 6, 2023

Jan. 6, 2023

Personally, I'd like to at least see 'America' renamed 'Americas', to both differentiate from the nickname for the USA, and to show there two continents (by traditional naming). ----- Original Message ----- From: Clive D.W. Feather via tz [mailto:tz@iana.org] To: "Wolfgang Keller" <wolfgangkeller(a)gmail.com> Cc: tz(a)iana.org Sent: Fri, 6 Jan 2023 21:46:47 +0000 Subject: Re: [tz] Split America into North America and South America Wolfgang Keller via tz said: > Hi, > let us consider what conventions for the number and separations of > continents exist. According to > > https://en.wikipedia.org/w/index.php?title=Continent&oldid=1131827063#N… > there exist (at least) five common conventions for the number and > separation of continents: > > a) 4 continents (Afro-Eurasia (Old World), America (New World), > Australia, Antarctica > b) 5 continents (Africa, Eurasia, America, Antarctica, Australia) > c) 6 continents, combined-Eurasia (Africa, Eurasia, North America, > South America, Antarctica, Australia) > d) 6 continents, combined-America (Africa, Asia, Europe, America, > Antarctica, Australia) > e) 7 continents (Africa, Asia, Europe, North America, South America, > Antarctica, Australia) You've forgotten Zealandia, which some consider to be a continent. > For the prevalence of these separations (prevalence of c)-e) taken > from the linked section of the Wikipedia article) > a) is to my knowledge motivated by geology > c) is is mostly used in Russia and some parts of Eastern Europe. > d) is taught in some countries where Romance languages are spoken and in Greece > e) is the model taught in most English-speaking countries > > So the central question that the problem reduces to is: which > separation of continents should tzdata implicitly endorse by its data > structures? If I were to ask, I would immediately say a) because this > is the only convention of this list that is motivated by science > (geology) and not by politics or history, I disagree. e is justifiable by geography: a continent doesn't have to be the largest contiguous landmass; it can be bordered by an isthmus or mountain range just as much as a puddle. But I don't see the need for this split. The division was made for the few humans who work with the raw data, not for the general public and certainly not for geologists. It works, so don't break it. -- Clive D.W. Feather | If you lie to the compiler, Email: clive(a)davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

2 1

Request for Russian Antarctic stations
by Benjamin Drung Jan. 6, 2023

Jan. 6, 2023

Hi, Ubuntu bug https://launchpad.net/bugs/1457285 requests to add Russian Antarctic research stations to tzdata. They are: AQ -6212-05858 Antarctica/Bellingshausen Bellingshausen Station, Vaterloo Island, GMT-4 AQ -7046+01149 Antarctica/Novolasarevskaya Novolasarevskaya Station, GMT AQ -6739+04530 Antarctica/Molodezhnaya Molodezhnaya Station, GMT+3 AQ -6633+09300 Antarctica/Mirniy Mirniy Station, GMT+7 AQ -6930+15923 Antarctica/Leningradskaya Leningradskaya Station, GMT+10 AQ -7445-13648 Antarctica/Russkaya Russkaya Station, GMT-6 AQ -6922+07623 Antarctica/Progress Progress Station, GMT+5 AQ -6944+07342 Antarctica/Druzhnaya Druzhnaya Station, GMT+5 Please mean that GMT data given are POSIX inversed. -- Benjamin Drung Debian & Ubuntu Developer

5 4

[PROPOSED] A couple more ptrdiff_t overflow safety checks
by Paul Eggert Jan. 4, 2023

Jan. 4, 2023

* private.h (TYPE_BIT): Now returns a signed value. * zdump.c (sumsize, xmalloc): Now takes signed args, like the result. (xstrsize): New function. (tzalloc, saveabbr): Use xstrsize to properly catch strings so long that their sizes do not fit into ptrdiff_t. Although quite implausible in real-life uses, it is possible according to the C standard. --- private.h | 2 +- zdump.c | 28 ++++++++++++++++++++-------- 2 files changed, 21 insertions(+), 9 deletions(-) diff --git a/private.h b/private.h index 03ee4d10..b638e9e4 100644 --- a/private.h +++ b/private.h @@ -805,7 +805,7 @@ ATTRIBUTE_REPRODUCIBLE time_t time2posix_z(timezone_t, time_t); ** Finally, some convenience items. */ -#define TYPE_BIT(type) (sizeof(type) * CHAR_BIT) +#define TYPE_BIT(type) (CHAR_BIT * (ptrdiff_t) sizeof(type)) #define TYPE_SIGNED(type) (((type) -1) < 0) #define TWOS_COMPLEMENT(t) ((t) ~ (t) 0 < 0) diff --git a/zdump.c b/zdump.c index 98537f4e..b93910ed 100644 --- a/zdump.c +++ b/zdump.c @@ -133,9 +133,9 @@ size_overflow(void) } /* Return A + B, exiting if the result would overflow either ptrdiff_t - or size_t. */ + or size_t. A and B are both nonnegative. */ ATTRIBUTE_REPRODUCIBLE static ptrdiff_t -sumsize(size_t a, size_t b) +sumsize(ptrdiff_t a, ptrdiff_t b) { #ifdef ckd_add ptrdiff_t sum; @@ -148,10 +148,22 @@ sumsize(size_t a, size_t b) size_overflow(); } +/* Return the size of of the string STR, including its trailing NUL. + Report an error and exit if this would exceed INDEX_MAX which means + pointer subtraction wouldn't work. */ +static ptrdiff_t +xstrsize(char const *str) +{ + size_t len = strlen(str); + if (len < INDEX_MAX) + return len + 1; + size_overflow(); +} + /* Return a pointer to a newly allocated buffer of size SIZE, exiting - on failure. SIZE should be nonzero. */ + on failure. SIZE should be positive. */ ATTRIBUTE_MALLOC static void * -xmalloc(size_t size) +xmalloc(ptrdiff_t size) { void *p = malloc(size); if (!p) { @@ -253,7 +265,7 @@ tzalloc(char const *val) static ptrdiff_t fakeenv0size; void *freeable = NULL; char **env = fakeenv, **initial_environ; - size_t valsize = strlen(val) + 1; + ptrdiff_t valsize = xstrsize(val); if (fakeenv0size < valsize) { char **e = environ, **to; ptrdiff_t initial_nenvptrs = 1; /* Counting the trailing NULL pointer. */ @@ -410,13 +422,13 @@ saveabbr(char **buf, ptrdiff_t *bufalloc, struct tm const *tmp) if (HAVE_LOCALTIME_RZ) return ab; else { - size_t ablen = strlen(ab); - if (*bufalloc <= ablen) { + ptrdiff_t absize = xstrsize(ab); + if (*bufalloc < absize) { free(*buf); /* Make the new buffer at least twice as long as the old, to avoid O(N**2) behavior on repeated calls. */ - *bufalloc = sumsize(*bufalloc, ablen + 1); + *bufalloc = sumsize(*bufalloc, absize); *buf = xmalloc(*bufalloc); } -- 2.37.2

1 0

Questions on tzname and tm_zone
by Patrik Lantto Dec. 31, 2022

Dec. 31, 2022

Dear all, I have a few questions regarding how the tzdb code handles tzname and tm_zone: * The define HAVE_TZNAME have three different "settings"; 0 if tzname is not supported, 1 to support tzname defined by the system library and 2 to support and define tzname. In the code though, when defining tzname it also adds the value of TZ_TIME_T which reduces the options. Basically, if time_tz is defined to another datatype that time_t, tzname cannot be defined by the system library since setting HAVE_TZNAME to 1 would still define tzname (around line 195 of localtime.c). Is there a reason for this behaviour (which is also similar for USG_COMPAT)? In my platform we define a new 64 bit datatype, but would still need tzname as defined by the system library. * In case of an invalid timezone, the behaviour of tzname and tm_zone behaves differently; tzname would be set to WILDABBR (which is possible to define), but if localtime is called tm_zone will be set to "UTC" while if gmtime is called, tm_zone is set to "-00" and if offtime is called (with a non-0 offset) tm_zone is WILDABBR. It seems somewhat inconsistent, so is this by design? * The way tzname is updated (in settzname) in settzname is that it first set tzname[0] and tzname[1] to either WILDABBR or UTC, and then possibly update with the correct names. While tzname is not considered thread safe, this way writing to tzname twice means that even call to tzset with the same timezone could affect other threads reading tzname. Not a huge risk, but still possible. Is this something to consider in the implementation? * Since tzname is not thread safe, and due to the way tm_zone is handled it is somewhat hard to detect if a TZ string is valid or not. Is there a recommended way to detect an invalid string? Best regards, Patrik Lantto -- Patrik Lantto - patrik.lantto(a)wisi.se - +46 13 210918

2 1

[PROPOSED] Support leap-seconds.list tombstone
by Paul Eggert Dec. 23, 2022

Dec. 23, 2022

From: Paul Eggert <eggert@trombone> This change looks forward to the possibility of leap seconds being discontinued by 2035. If and when that happens, the expiration date on the leap-seconds.list file is likely to stop being maintained, as there will be no need to issue new versions of leap-seconds.list every six months. Although the details have not been decided, for now assume that the last edition of leap-seconds.list will simply lack an expiration-date line. * leapseconds.awk: If the input lacks an expiration line like ‘#@ 3896899200’, do not treat it as if ‘#@ 0’ were present, as that would mean an expiration date of 1900-01-01. Instead, do not output an expiration date; just output a comment saying that there is no expiration date. Similarly for update dates and input lacking lines like ’#$ 3676924800’. --- NEWS | 3 +++ leapseconds.awk | 50 ++++++++++++++++++++++++++++++------------------- 2 files changed, 34 insertions(+), 19 deletions(-) diff --git a/NEWS b/NEWS index 9ac3367..5510823 100644 --- a/NEWS +++ b/NEWS @@ -42,6 +42,9 @@ Unreleased, experimental changes 'restrict' keyword consistently with their documentation. This may allow future optimizations. + leapseconds.awk can now process a leap seconds file that never + expires; this might be useful if leap seconds are discontinued. + Changes to commentary Note that leap seconds are planned to be discontinued by 2035. diff --git a/leapseconds.awk b/leapseconds.awk index b6c48bc..7d2556b 100644 --- a/leapseconds.awk +++ b/leapseconds.awk @@ -104,18 +104,23 @@ BEGIN { } END { - sstamp_to_ymdhMs(expires, ss_NTP) - print "" - print "# UTC timestamp when this leap second list expires." - print "# Any additional leap seconds will come after this." - if (! EXPIRES_LINE) { - print "# This Expires line is commented out for now," - print "# so that pre-2020a zic implementations do not reject this file." + + if (expires) { + sstamp_to_ymdhMs(expires, ss_NTP) + + print "# UTC timestamp when this leap second list expires." + print "# Any additional leap seconds will come after this." + if (! EXPIRES_LINE) { + print "# This Expires line is commented out for now," + print "# so that pre-2020a zic implementations do not reject this file." + } + printf "%sExpires %.4d\t%s\t%.2d\t%.2d:%.2d:%.2d\n", \ + EXPIRES_LINE ? "" : "#", \ + ss_year, monthabbr[ss_month], ss_mday, ss_hour, ss_min, ss_sec + } else { + print "# (No Expires line, since the expires time is unknown.)" } - printf "%sExpires %.4d\t%s\t%.2d\t%.2d:%.2d:%.2d\n", \ - EXPIRES_LINE ? "" : "#", \ - ss_year, monthabbr[ss_month], ss_mday, ss_hour, ss_min, ss_sec # The difference between the NTP and POSIX epochs is 70 years # (including 17 leap days), each 24 hours of 60 minutes of 60 @@ -124,15 +129,22 @@ END { print "" print "# POSIX timestamps for the data in this file:" - sstamp_to_ymdhMs(updated, ss_NTP) - printf "#updated %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ - updated - epoch_minus_NTP, \ - ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec - sstamp_to_ymdhMs(expires, ss_NTP) - printf "#expires %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ - expires - epoch_minus_NTP, \ - ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec - + if (updated) { + sstamp_to_ymdhMs(updated, ss_NTP) + printf "#updated %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ + updated - epoch_minus_NTP, \ + ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec + } else { + print "#(updated time unknown)" + } + if (expires) { + sstamp_to_ymdhMs(expires, ss_NTP) + printf "#expires %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ + expires - epoch_minus_NTP, \ + ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec + } else { + print "#(expires time unknown)" + } printf "\n%s", last_lines } -- 2.38.1

1 0

Re: [tz] [PROPOSED] Mention the planned obsolescence of leap seconds
by Brian Inglis Dec. 22, 2022

Dec. 22, 2022

On 2022-12-20 17:25, Paul Eggert via tz wrote: > + Changes to commentary > + Note that leap seconds are planned to be discontinued by 2035. > + This affects time stamps during the leap second era (1972–2035). > +Leap seconds were introduced in 1972 to accommodate the > +difference between atomic time and the less-regular rotation of the earth. > +Unfortunately they caused so many problems with civil Civil (e.g. legal etc.) time keeping is not the problem, it is mainly proprietary computer systems and applications, not adequately programmed to deal with the realities of time keeping. > +timekeeping that they > +are <a href="https://www.bipm.org/en/cgpm-2022/resolution-4">planned > +to be discontinued by 2035</a>, with some as-yet-undetermined > +mechanism replacing them, perhaps after the year 2135. > +Despite their impending obsolescence, a record of leap seconds is still > +needed to resolve timestamps from 1972 through 2035. I would expect astronomers and physicists to have divergent views, but both use software which handles varieties of time bases, scales, and conversions. It seems likely that other scientists and disciplines with time concerns would line up behind one or the other, depending on whether their focus is civil, geocentric, or longer term in some way, or more artificial on accuracy, calibration, precision or other short term characteristics. > <a href="https://www.ucolick.org/~sla/leapsecs/"><abbr>UTC</abbr> > might be redefined > without Leap Seconds</a> gives pointers on this > +contentious issue. > +The General Conference on Weights and Measures > +<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">voted in 2022</a> > +to discontinue the use of leap seconds by 2035, replacing them with an > +as-yet-undetermined scheme some time after the year 2135. Expect every lawyer, in any case involving time stamped records, to jump on the technicality of any significant deviation of time keeping from solar time, which is the legal basis in most English common law jurisdictions, possibly also in some continental code and Scandinavian/Nordic jurisdictions e.g. Denmark: https://www.dr.dk/nyheder/indland/uret-paa-din-telefon-viser-en-ulovlig-tid https://www-dr-dk.translate.goog/nyheder/indland/uret-paa-din-telefon-viser… -- 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

1 0

DST in the news
by Arthur David Olson Dec. 22, 2022

Dec. 22, 2022

A 538 piece on the merits and demerits of permanent standard time and permanent daylight time. https://projects.fivethirtyeight.com/daylight-saving-time/ --ado

1 0

[PROPOSED] Document deprecation of ctime, asctime.
by Paul Eggert Dec. 21, 2022

Dec. 21, 2022

--- newctime.3 | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/newctime.3 b/newctime.3 index e25d841..2790c81 100644 --- a/newctime.3 +++ b/newctime.3 @@ -11,13 +11,13 @@ asctime, ctime, difftime, gmtime, localtime, mktime \- convert date and time .PP .BR "extern char *tzname[];" " /\(** (optional) \(**/" .PP -.B char *ctime(time_t const *clock); +.B [[deprecated]] char *ctime(time_t const *clock); .PP .B char *ctime_r(time_t const *clock, char *buf); .PP .B double difftime(time_t time1, time_t time0); .PP -.B char *asctime(struct tm const *tm); +.B [[deprecated]] char *asctime(struct tm const *tm); .PP .B "char *asctime_r(struct tm const *restrict tm," .B " char *restrict result);" @@ -91,6 +91,15 @@ introduction of UTC and are some other flavor of Universal Time (UT). Some implementations support leap seconds, in contradiction to POSIX. .PP The +.B ctime +function is deprecated starting in C23. +Callers can use +.B localtime_r +and +.B strftime +instead. +.PP +The .B localtime and .B gmtime @@ -128,6 +137,10 @@ converts a time value contained in a structure to a string, as shown in the above example, and returns a pointer to the string. +This function is deprecated starting in C23. +Callers can use +.B strftime +instead. .PP The .B mktime -- 2.38.1

1 0