- tz - lists.iana.org

localized date without time
by Alejandro Colomar Feb. 12, 2025

Feb. 12, 2025

Hi Paul, Link: <https://github.com/shadow-maint/shadow/issues/1057> Currently, shadow utils' passwd(1) (and several other programs) uses UTC time when printing. That is: $ passwd -S alx alx P 2023-09-20 0 99999 7 -1 the date from above is a UTC representation of $ sudo cat /etc/shadow | grep alx | cut -f3 -d: 19620 However, shadow utils programs, such as chage(1), use local time in input. That timestamp was set by chage(1), interpreting a local date: $ sudo chage -d 2023-09-21 alx $ sudo cat /etc/shadow | grep alx | cut -f3 -d: 19620 $ date Wed Jul 31 07:54:17 CEST 2024 This is rather confusing, and we think that passwd(1) should also print the date in local time, when printing human-readable dates. However, I think it might be better to show the timezone information together with the date, to be clear that what we're printing is local time. Do you think that's reasonable? Or maybe it's understood that when printing a date some timezone information is implicitly local? I didn't find any way to print timezone information in ISO 8601, if you don't print the time together with the date. That is, ISO 8601 says: C.1.3.1 Date A date string represents one of the following: • year, month, and day (e.g. 2001-02-03) • year and month (e.g. 2008-12 ) • year (e.g. 2008) and C.1.3.2 Date and Time A date/time string is composed according to one of three representations as illustrated in the following three examples: • 2001-02-03T09:30:01 • 2004-01-01T10:10:10Z • 2004-01-01T10:10:10+05:00 but I don't see any way to print something like 2023-09-21+02:00 in standardese. Is this a defect in ISO 8691? I see that in C.1.3.2, it says "Zone-offset may be omitted or included", so I guess we can just omit it. What do you think we should do? Thanks! And have a lovely day! Alex -- <https://www.alejandro-colomar.es/>

5 17

ELIZA Reanimated
by Brooks Harris Jan. 23, 2025

Jan. 23, 2025

ELIZA Reanimated: The world’s first chatbot restored on the world’s first time sharing system https://arxiv.org/pdf/2501.06707 Has anyone asked ELIZA what time it is?

3 3

Re: Notice of a problem with the Asia/Tokyo time zone
by Paul Eggert Jan. 22, 2025

Jan. 22, 2025

> From: Patrick BENNY <patrick.benny(a)mixi.co.jp> > Date: Mon, Jan 20, 2025 at 6:41 PM > The Asia/Tokyo time zone seems to have been linked with Australia, probably > by mistake. > Please see this related difference from the zone1970.tab file, observed > when comparing 2024b and 2025a. > > 186c186 > < JP +353916+1394441 Asia/Tokyo > --- >> JP,AU +353916+1394441 Asia/Tokyo Eyre Bird Observatory > > The Eyre Bird Observatory should probably be linked with an Australian time > zone instead of Asia/Tokyo. Actually that line should be OK, as the Eyre Bird Observatory region (unlike the rest of Australia) has observed Tokyo time since 1970. The comments at the start of zone1970.tab say this about the "Eyre Bird Observatory" in column 4: # Comments; present if and only if countries have multiple timezones, # and useful only for those countries. For example, the comments # for the row with countries CH,DE,LI and name Europe/Zurich # are useful only for DE, since CH and LI have no other timezones. "Eyre Bird Observatory" is useful only for AU, since JP has no other timezones; so this is another example of that column-4 idea.

4 4

Medovukha factory in Kazakhstan advances its clocks by 1/20 of a day
by Paul Eggert Jan. 21, 2025

Jan. 21, 2025

Last year's move to unify Kazakhstan into a single UTC+05 time zone is seeing some pushback. In "Anger over Kazakh Time Zones" (2024-12-24)[1] RFE/RL's Chris Rickleton and Tasqyn Bolatuly reported that one lawmaker asserted that a majority his party in parliament would support a law to reverse the decision. Although government executive officials still strongly support the move, we'll need to keep an eye on the situation. Rickleton and Bolatuly also reported how one private firm is addressing the problem: > Almas Tangytuli, the owner of a company that produces medovukha, a honey-based alcoholic drink similar to mead, says he is already doing something similar. > > After struggling with the new time, he set the clocks at his factory just east of Oskemen forward by a 1 1/5 hour for the sake of his workers, who keep livestock in villages nearby. > > "After work, there was no time for them to sort out their barns in the steppe, where there is no lighting. In the morning, their cattle make a rush for the fields. You can't tell cattle that the clocks have changed," Tangytuli told RFE/RL. 1 1/5 hour is 72 minutes, or 1/20 of a day. I wonder where Tangytuli got that number? Oskemen is about 5.5 hours ahead of UTC, so he has overcorrected and is about 0.7 hours ahead of local mean time; surely this is not entirely for the sake of the cows. The fractional hour vaguely reminds me of William Willett's 1907 proposal to implement daylight saving time by advancing clocks by 20 minutes each in four successive Sundays.[2] But although Willett wanted his construction workers to get to his worksites earlier during the day, he wrote nothing about his workers' cows. [1]: https://www.rferl.org/a/33249639.html [2]: https://www.webexhibits.org/daylightsaving/willett.html

1 0

Re: [tz-announce] 2025a release of tz code and data available
by Paul Eggert Jan. 21, 2025

Jan. 21, 2025

On 2025-01-16 11:21, Geert Hendrickx wrote: > On Thu, Jan 16, 2025 at 09:37:50 -0800, Paul Eggert via tz-announce via tz wrote: >> ... Paraguay adopts permanent -03 starting spring 2024. > > starting spring *2025* ? Actually, "spring 2024" is correct. Release 2025a says the legal change occurred in Paraguay on 2024-10-15 at 00:00, which is spring in the southern hemisphere. The clocks didn't change then: only tm_isdst changed, and since tm_isdst is obsolescent that wasn't enough to prompt a new TZDB release right away. The first change to predicted timestamps is this year on March 22 at 00:00, when Paraguay is now predicted to stay at -03 instead of falling back from -03 to -04. This will be autumn in the southern hemisphere.

1 1

[tz-announce] 2025a release of tz code and data available
by Paul Eggert via tz-announce Jan. 16, 2025

Jan. 16, 2025

The 2025a release of the tz code and data is available. This release contains the following changes: Briefly: Paraguay adopts permanent -03 starting spring 2024. Improve pre-1991 data for the Philippines. Etc/Unknown is now reserved. Changes to future timestamps Paraguay will stop changing its clocks after the spring-forward transition on 2024-10-06, so it is now permanently at -03. (Thanks to Heitor David Pinto and Even Scharning.) This affects timestamps starting 2025-03-22, as well as the obsolescent tm_isdst flags starting 2024-10-15. Changes to past timestamps Correct timestamps for the Philippines before 1900, and from 1937 through 1990. (Thanks to P Chan for the heads-up and citations.) This includes adjusting local mean time before 1899; fixing transitions in September 1899, January 1937, and June 1954; adding transitions in December 1941, November 1945, March and September 1977, and May and July 1990; and removing incorrect transitions in March and September 1978. Changes to data Add zone1970.tab lines for the Concordia and Eyre Bird Observatory research stations. (Thanks to Derick Rethans and Jule Dabars.) Changes to code strftime %s now generates the correct numeric string even when the represented number does not fit into time_t. This is better than generating the numeric equivalent of (time_t) -1, as strftime did in TZDB releases 96a (when %s was introduced) through 2020a and in releases 2022b through 2024b. It is also better than failing and returning 0, as strftime did in releases 2020b through 2022a. strftime now outputs an invalid conversion specifier as-is, instead of eliding the leading '%', which confused debugging. An invalid TZ now generates the time zone abbreviation "-00", not "UTC", to help the user see that an error has occurred. (Thanks to Arthur David Olson for suggesting a "wrong result".) mktime and timeoff no longer incorrectly fail merely because a struct tm component near INT_MIN or INT_MAX overflows when a lower-order component carries into it. TZNAME_MAXIMUM, the maximum number of bytes in a proleptic TZ string's time zone abbreviation, now defaults to 254 not 255. This helps reduce the size of internal state from 25480 to 21384 on common platforms. This change should not be a problem, as nobody uses such long "abbreviations" and the longstanding tzcode maximum was 16 until release 2023a. For those who prefer no arbitrary limits, you can now specify TZNAME_MAXIMUM values up to PTRDIFF_MAX, a limit forced by C anyway; formerly tzcode silently misbehaved unless TZNAME_MAXIMUM was less than INT_MAX. tzset and related functions no longer leak a file descriptor if another thread forks or execs at about the same time and if the platform has O_CLOFORK and O_CLOEXEC respectively. Also, the functions no longer let a TZif file become a controlling terminal. 'zdump -' now reads TZif data from /dev/stdin. (From a question by Arthur David Olson.) Changes to documentation The name Etc/Unknown is now reserved: it will not be used by TZDB. This is for compatibility with CLDR, which uses the string "Etc/Unknown" for an unknown or invalid timezone. (Thanks to Justin Grant, Mark Davis, and Guy Harris.) Cite Internet RFC 9636, which obsoletes RFC 8536 for TZif format. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2025a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2025a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2025a.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit a8e2fcd87bc5f83fec0a76652095e8d7881b0763 dated 2025-01-15 10:47:24 -0800 and tagged '2025a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 308f6a3d6ebfa18446f8296e5c799e18dccecd79ace3ba004d3f233892c7428faae152b217b22d229c59dd4e0faafee797d8b3583b58fa982b81f7cc7347f502 tzcode2025a.tar.gz 93b8f939d39bdfe451e262666f9099c529c96c49d14c08e3611560ca660e12e16d08a22b145d615e00570fb194881618d6f9a0a617c119ab447be03279d747c3 tzdata2025a.tar.gz 1e8c4e141158d63ca5c39babc9d18c32df14e2e59bc7649a7fed8c3e577f7b175bafa43883cf351139ff198515f5f8c22b1418e2ac7efb7f837faa8f61d2574d tzdb-2025a.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmeIA2oACgkQ7ZfpDmKq fjT4TA//dFIBsmsl3OJ7QdI3lnySSQWyNnZQjsue3qtw7dUp0nbbFd7QGegrVDSC zrY+v51AVm9sk9hLdLQuyVFm5xRqXuBp2fC70wFeCCocEMp4HnhOogJVXMqQz+Dy AFZ8U7HmtNUI+ca9MTw6WTpQ5DOy6Of5rer3LbicmzBgVQ/UNcoIFZs4qf+RnMYY GKOHfLDLhs/4fQf3+zfELLbavieOoqcQlp8HntZrCuR2zZZNImVkt0/ljtTnHqd/ b0KUMDbYQ2dGsNbpBQS5GhAUjVPeUB5npqfA0ibS1gv1e99yWwGeMmUY3GqFbQWn dNN5LTceS9/H/+thtgN+70g4b2Haz+So91AiXKMNxgvb9qkjqV+2ZFd04ud4hapz +rRV8y1VDP/QEmXwL4zMnx+xkzGr3xTh+0z67R3RBIbL5eRGQojjKN1BLkYTWRsx VfaI51+GJWKjlX1Mo9OoSGGWgRWPgn591dYcep+cKA9jYSMzO48VOsdABIt3tTbX 7zqONqpDt6JZJJL7UdH2A0Lik8nkGFnSAnuuwW948CGh26odotoXAC15xWbK18VN v6T+zGZoLR8PdVlIYPjNUyS0sqo6tZtHa3Nci99+A5XG30oX+ecz/zlyDuRBLWkI 31bmm5423PHZ4N94Yi2V6xAC2G7mHn9m7eYv71C6Pg6fs5vOTgA= =2Ldn -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmeIA2oACgkQ7ZfpDmKq fjREhxAAjB1QDroFoq07V+56IIrJR3pK/x4Z2jBbg53N49Cam1oMZK5Wxm291d0G lPutNQvjiNubnBG4pgMMQ2xEF6jgYY0eFfLlORGK9IoW8e3lnlAqSR9BsOQvWjeA lKfmBkhFXetSJ8gu2ModVybpVIqDaJJ73sNQSsA01MHwz0RLV5CLOHXitJ8lBO68 vdSArRhalLUEIVytAKyy1a0msFdzrrDj/7q6tMV9NDY1xQg4V9TLxnPNds29H0x8 xO2zrDug6zrbg9z994JYkhq9h9DLe5h4F3StnaDwRK8eLLRq5D7ryK77Z8dtyXZf tDPgiNc1MquSg48481dDiUfsRdN5S2OLVFqjyWUuwVKBSkSRv/nBQqisGEybY86T H84D5WA0zlj8mFJyuKFmvGHzzKZ6X7mUNrTObaY3G+QHgHjIKWqO7oog447YOYOG DSA5rSmYrzZp2RXP/doeFZD+2kbNVPlN8zBh6lANABwvFH6IhDI+/OJzGJqeYotz ZWVoU3um6aToMS4Uv2PdBNbH1W1P1pzzMM5TJ/bQO/ujCwaBSTwoDPJT6tW9BLrO gJUWd1AumocieAWc0Vyzbrpzbo7Vc//1LF+s1eI+zWt8925unFrBArvQ4h/PyXsc O5LhOQVm1986y9xy2YyF+Cy5s+xsKvKENQ0NbLIDa+l5MdEdEXc= =NQgW -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmeIA2sACgkQ7ZfpDmKq fjQkcQ/+MWIjE3J5FETCaYxUvElzWIN25Jx4p3dBp4CL/UqD9qW/3CRiRt7KbS5Q 2C1+Hg5DKGAJJ/9/L72t4ttMheskUkGyI/M/xWuG2EKMRPJd3zEPZItSfJOtbBwo vmmTIe9s/yZTkmeoMQ/PVdhci6rwifwUEopxq3V2pTBIBnj6H+hBlSLL8Y7RgbWQ yDlzf1HvfnQ+4xlhtcDNb49iljlrPEwUJZe+2RSPmxAtAHe6SJK4i9tSQlv0fJew whM0//rlihNKRG04TFJ4lw5UeueCKhLL8E/HLbLewVcJcbd4pHMFNmdxi17VHmZj IG1tj75Ff69dyuZiCkuOe9S5SzKlI40FEU3aN1k7wWz3PzBbGBWt9CMxNY35DpLF Di23QeTOvdDEEccjivRVyNc4mwthnylOcmKcE5RYhT45W+Tpr0BhLnE29/ZwZ3Dy EB8wQJvGZWh6LVK2C7unEmQaYmPD+pl8WoZ9MmZHnR0YmNd/NfcefKX/UenLs5+J HIifuTWnzRfA4DQTbV+l/kNUzOo/asoD98qQ6/2inDEQWCZpg1V1sOFcHVYkb6XX LT7PUnC5eiKS8U47KBzTTwkEAWij/LKD+gnksjfkzU/Pn5MpzXm4qwVo7v9yuEal i4nIbqzuY8iK0SYBw0da8W10dFtB3bgtfUuSTXQLCP8sWVI34bY= =B68m -----END PGP SIGNATURE-----

1 0

Re: Windows compile failure for iana time zones
by Paul Eggert Jan. 15, 2025

Jan. 15, 2025

On 1/13/25 05:17, Manuela Friedrich wrote: > It seems that your commit 1ee9daa91818f5d4ab6937352453813fa333e105 > fails with: > localtime.c(309): error C2099: initializer is not a constant Thanks for reporting that. Which compiler are you using and what version and what compiler flags are you using? Does the following uninstalled patch fix things for you? If not, what's the value of _MSC_VER when you use your compiler flags? diff --git a/private.h b/private.h index 0a546e02..3e64da4e 100644 --- a/private.h +++ b/private.h @@ -26,7 +26,11 @@ because RHEL 7 (whose GCC defaults to C89) extended life cycle support (ELS) is scheduled to end on 2028-06-30. */ #ifndef PORT_TO_C89 -# define PORT_TO_C89 0 +# if defined _MSC_VER && _MSC_VER < 1800 +# define PORT_TO_C89 1 +# else +# define PORT_TO_C89 0 +# endif #endif /* SUPPORT_C89 means the tzcode library should support C89 callers Perhaps we could use the patch with a different value in place of 1800, or perhaps we should just remove the " && _MSC_VER < 1800". Microsoft says[1] that it didn't add support for C99-style compound literals until Visual Studio 2013. Are you using an older version of MSVC? If so, it's past end-of-life[2] and I doubt whether we should worry about it. [1]: https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-stu… [2]: https://devblogs.microsoft.com/visualstudio/support-ends-for-older-versions…

3 5

Paraguay may adopt permanent DST soon
by Heitor David Pinto Jan. 13, 2025

Jan. 13, 2025

Today the Congress of Paraguay passed a bill to observe UTC-3 permanently, equivalent to permanent DST. The bill still needs to be approved by the president. https://www.abc.com.py/politica/2024/09/24/congreso-sanciona-horario-de-ver… The text of the bill says that it would enter into force on the first Sunday in October 2024, the same date currently scheduled to start DST. But in practice, it would only make a difference from the fourth Sunday of March 2025, the date currently scheduled to end DST. https://silpy.congreso.gov.py/web/expediente/132531

10 20

[PROPOSED 1/3] Alias asctime, ctime result
by Paul Eggert Jan. 10, 2025

Jan. 10, 2025

I misread C99, and in a 2022-11-30 patch caused asctime and ctime to return different pointers when !SUPPORT_C89. However, C99 and later still require that these two functions return the same pointers, so revert that part of the 2022-11-30 change. * asctime.c (buf_ctime): Remove. All uses replaced with buf_asctime. --- asctime.c | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/asctime.c b/asctime.c index 1bfcafe9..491d23bf 100644 --- a/asctime.c +++ b/asctime.c @@ -30,16 +30,6 @@ enum { STD_ASCTIME_BUF_SIZE = 26 }; */ static char buf_asctime[2*3 + 5*INT_STRLEN_MAXIMUM(int) + 7 + 2 + 1 + 1]; -/* A similar buffer for ctime. - C89 requires that they be the same buffer. - This requirement was removed in C99, so support it only if requested, - as support is more likely to lead to bugs in badly written programs. */ -#if SUPPORT_C89 -# define buf_ctime buf_asctime -#else -static char buf_ctime[sizeof buf_asctime]; -#endif - /* On pre-C99 platforms, a snprintf substitute good enough for us. */ #if !HAVE_SNPRINTF # include <stdarg.h> @@ -86,8 +76,7 @@ asctime_r(struct tm const *restrict timeptr, char *restrict buf) register const char * mn; int year, mday, hour, min, sec; long long_TM_YEAR_BASE = TM_YEAR_BASE; - size_t bufsize = ((buf == buf_ctime - || (!SUPPORT_C89 && buf == buf_asctime)) + size_t bufsize = (buf == buf_asctime ? sizeof buf_asctime : STD_ASCTIME_BUF_SIZE); if (timeptr == NULL) { -- 2.47.1

1 2

v2024b Mexico rules
by Ertan Küçükoglu Jan. 8, 2025

Jan. 8, 2025

Hello, Below is a section taken from v2024b northamerica file # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Mexico 1931 only - April 30 0:00 1:00 D Rule Mexico 1931 only - Oct 1 0:00 0 S Rule Mexico 1939 only - Feb 5 0:00 1:00 D Rule Mexico 1939 only - Jun 25 0:00 0 S Rule Mexico 1940 only - Dec 9 0:00 1:00 D Rule Mexico 1941 only - Apr 1 0:00 0 S Rule Mexico 1943 only - Dec 16 0:00 1:00 W # War Rule Mexico 1944 only - May 1 0:00 0 S Rule Mexico 1950 only - Feb 12 0:00 1:00 D Rule Mexico 1950 only - Jul 30 0:00 0 S Rule Mexico 1996 2000 - Apr Sun>=1 2:00 1:00 D Rule Mexico 1996 2000 - Oct lastSun 2:00 0 S Rule Mexico 2001 only - May Sun>=1 2:00 1:00 D Rule Mexico 2001 only - Sep lastSun 2:00 0 S Rule Mexico 2002 2022 - Apr Sun>=1 2:00 1:00 D Rule Mexico 2002 2022 - Oct lastSun 2:00 0 S If you look closely, the first rule has the full month name April written and not a three letter short version like the rest of the list. I wonder if that is the new format and not an error. Thanks & Regards, Ertan

2 1

[PROPOSED 1/7] Modernize date man page
by Paul Eggert Jan. 8, 2025

Jan. 8, 2025

* date.1: Update the example to next year. Remove duplication of spec with strftime, as this is too much of a pain to maintain separately for what is just a demo; but give an example for clarity. Update list of files accessed, to match current code. --- date.1 | 110 +++++++++------------------------------------------------ 1 file changed, 16 insertions(+), 94 deletions(-) diff --git a/date.1 b/date.1 index 01907bc7..9b025bc9 100644 --- a/date.1 +++ b/date.1 @@ -35,7 +35,7 @@ command without arguments writes the date and time to the standard output in the form .ce 1 -Wed Mar 8 14:54:40 EST 1989 +Sat Mar 8 14:54:40 EST 2025 .br with .B EST @@ -49,92 +49,17 @@ If a command-line argument starts with a plus sign (\c .q "\fB+\fP" ), the rest of the argument is used as a .I format -that controls what appears in the output. -In the format, when a percent sign (\c -.q "\fB%\fP" -appears, -it and the character after it are not output, -but rather identify part of the date or time -to be output in a particular way -(or identify a special character to output): -.nf -.sp -.if t .in +.5i -.if n .in +2 -.ta \w'%M\0\0'u +\w'Wed Mar 8 14:54:40 EST 1989\0\0'u - Sample output Explanation -%a Wed Abbreviated weekday name* -%A Wednesday Full weekday name* -%b Mar Abbreviated month name* -%B March Full month name* -%c Wed Mar 08 14:54:40 1989 Date and time* -%C 19 Century -%d 08 Day of month (always two digits) -%D 03/08/89 Month/day/year (eight characters) -%e 8 Day of month (leading zero blanked) -%h Mar Abbreviated month name* -%H 14 24-hour-clock hour (two digits) -%I 02 12-hour-clock hour (two digits) -%j 067 Julian day number (three digits) -%k 2 12-hour-clock hour (leading zero blanked) -%l 14 24-hour-clock hour (leading zero blanked) -%m 03 Month number (two digits) -%M 54 Minute (two digits) -%n \\n newline character -%p PM AM/PM designation -%r 02:54:40 PM Hour:minute:second AM/PM designation -%R 14:54 Hour:minute -%S 40 Second (two digits) -%t \\t tab character -%T 14:54:40 Hour:minute:second -%U 10 Sunday-based week number (two digits) -%w 3 Day number (one digit, Sunday is 0) -%W 10 Monday-based week number (two digits) -%x 03/08/89 Date* -%X 14:54:40 Time* -%y 89 Last two digits of year -%Y 1989 Year in full -%z -0500 Numeric time zone -%Z EST Time zone abbreviation -%+ Wed Mar 8 14:54:40 EST 1989 Default output format* -.if t .in -.5i -.if n .in -2 -* The exact output depends on the locale. -.sp -.fi -If a character other than one of those shown above appears after -a percent sign in the format, -that following character is output. -All other characters in the format are copied unchanged to the output; -a newline character is always added at the end of the output. -.PP -In Sunday-based week numbering, -the first Sunday of the year begins week 1; -days preceding it are part of -.q "week 0" . -In Monday-based week numbering, -the first Monday of the year begins week 1. -.PP -To set the date, use a command line argument with one of the following forms: -.nf -.if t .in +.5i -.if n .in +2 -.ta \w'198903081454\0'u -1454 24-hour-clock hours (first two digits) and minutes -081454 Month day (first two digits), hours, and minutes -03081454 Month (two digits, January is 01), month day, hours, minutes -8903081454 Year, month, month day, hours, minutes -0308145489 Month, month day, hours, minutes, year - (on System V-compatible systems) -030814541989 Month, month day, hours, minutes, four-digit year -198903081454 Four-digit year, month, month day, hours, minutes -.if t .in -.5i -.if n .in -2 -.fi -If the century, year, month, or month day is not given, -the current value is used. -Any of the above forms may be followed by a period and two digits that give -the seconds part of the new time; if no seconds are given, zero is assumed. +that is processed by +.BR strftime (3) +to determine what to output; +a newline character is appended. +For example, the shell command: +.ce 1 +date +"%Y\*-%m\*-%d %H:%M:%S %z" +.br +outputs a line like +.q "2025\*-03\*-08 14:54:40 \*-0500" +instead. .PP These options are available: .TP @@ -149,16 +74,13 @@ past the epoch of 1970-01-01 00:00:00 UTC, where should be an integer, either decimal, octal (leading 0), or hexadecimal (leading 0x), preceded by an optional sign. .SH FILES -.ta \w'/usr/share/zoneinfo/posixrules\0\0'u +.ta \w'/usr/share/zoneinfo/Etc/UTC\0\0'u /etc/localtime local timezone file .br /usr/lib/locale/\f2L\fP/LC_TIME description of time locale \f2L\fP .br /usr/share/zoneinfo timezone directory .br -/usr/share/zoneinfo/posixrules default DST rules (obsolete) -.br -/usr/share/zoneinfo/GMT for UTC leap seconds -.PP -If /usr/share/zoneinfo/GMT is absent, -UTC leap seconds are loaded from /usr/share/zoneinfo/GMT0 if present. +/usr/share/zoneinfo/Etc/UTC for UTC leap seconds +.SH SEE ALSO +.BR strftime (3). -- 2.47.1

1 6

Fwd: Bulletin C number 69
by Tim Parenti Jan. 7, 2025

Jan. 7, 2025

No leap second 2025-06-30, per below. See attached patch. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Tue, 7 Jan 2025 at 05:00 Subject: Bulletin C number 69 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, 06 January 2025 Bulletin C 69 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 2025. 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

Y2K on the radio
by Arthur Olson Dec. 31, 2024

Dec. 31, 2024

With a New Year looming, an NPR Y2K review. (Alas, no mention of T2G in 2038.) @dashdashado https://www.npr.org/2024/12/28/nx-s1-5116271/y2k-year-2000-preparations

3 2

[PROPOSED] For timestamps compare to HEAD not to index
by Paul Eggert Dec. 30, 2024

Dec. 30, 2024

Problem reported by Bruno Haible in: https://lists.gnu.org/r/bug-gnulib/2024-12/msg00245.html * Makefile (set-timestamps.out): When comparing working file to repository, Use ‘git diff HEAD’ instead of plain ‘git diff’. --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index ffdbfe3b..e00b0f32 100644 --- a/Makefile +++ b/Makefile @@ -1104,7 +1104,7 @@ set-timestamps.out: $(EIGHT_YARDS) touch -md @1 test.out; then \ rm -f test.out && \ for file in $$files; do \ - if git diff --quiet $$file; then \ + if git diff --quiet HEAD $$file; then \ time=$$(TZ=UTC0 git log -1 \ --format='tformat:%cd' \ --date='format:%Y-%m-%dT%H:%M:%SZ' \ -- 2.47.1

1 0

Deprecate two digit year formats %D %g %y
by Brian Inglis Dec. 29, 2024

Dec. 29, 2024

Hi folks, [Spurred by NPR Y2K review article.] Could we please all make a New Year's resolution to stop people from reviving two digit year formats that are starting to reappear, making it impossible to figure out some intended dates, and officially deprecate all two digit year formats %D %g %y across all standards, and tools default to options like gcc's and clang's -Wformat-y2k (included in -Wformat=2) and clang's -Wdeprecate. -- 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

Request for inclusion of Trivandrum in the IANA Time Zone Database
by Anish shivaraj Dec. 28, 2024

Dec. 28, 2024

Dear tzdata Maintainers, I am writing to propose the inclusion of Trivandrum (Thiruvananthapuram) as a new entry in the IANA Time Zone Database (tzdata). As the capital city of Kerala, Trivandrum holds significant historical, economic, and technological importance, and its addition to the database would reflect its growing prominence. Justification for Inclusion Population and Prominence With a population exceeding 1 million, Trivandrum is well above the 300,000 threshold for inclusion.The city serves as a political, cultural, and economic hub in southern India. Economic Growth and Commercial Significance Vizhinjam International Seaport: Trivandrum is home to India’s first transshipment port, the Vizhinjam International Seaport, which is expected to position the city as a major player in global shipping and logistics. Emerging Commercial Hub: The growth of the Vizhinjam port has already made Trivandrum an important center for commerce, attractingsignificant investments and fostering local economic development. Technological and Space Research Importance India’s First IT Park: Technopark in Trivandrum is the country’s first and one of the largest IT parks, contributing greatly to India’s IT industry. Space Research and Education: The city houses the Vikram Sarabhai Space Centre (VSSC), a key institution for India’s space exploration efforts. Trivandrum also hosts the Indian Institute of Space Science and Technology (IIST) and the Kerala Space Park, making it a critical hub for space research and innovation. Eligibility Based on Time Zone Criteria Unique Timekeeping History: Trivandrum once had its own local mean time before the adoption of Indian Standard Time (IST), making this distinction relevant for its case. Representative Need: As an emerging commercial, technological,and research center, a separate time zone entry would provide better representation for the region’s users and applications. Alignment with tzdata Objectives - Trivandrum meets the criteria of significant population, historical relevance, and global contributions to shipping, IT, and space research, making it a suitable candidate for inclusion. Proposed Time Zone Entry We suggest adding the following entry: Zone Asia/Trivandrum +05:30 - Trivandrum Standard Time Including Trivandrum in the tzdata database would provide better localization and reflect its growing importance. Thank you for considering this request. Should you require further information or clarification, please do not hesitate to reach out. Best regards, Anish Sivarajan

3 3

Re: Iana build failures on Windows
by Paul Eggert Dec. 19, 2024

Dec. 19, 2024

On 2024-12-17 07:53, Manuela Friedrich wrote: > It's worth noticing that I had to add -DHAVE_SYS_STAT_H=0 to the tools.ini > file we use on Windows. Thanks for mentioning that, but unfortunately I don't know why -DHAVE_SYS_STAT_H=0 was needed (I don't use MS-Windows). Some fumbling with Microsoft documentation eventually led me to <https://learn.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=…> which hints (but does not say) that by default MS-Windows <sys/stat.h> doesn't define the 'stat' function if you use some compilation options. I installed the attached patch to try to work around this portability problem. Does this patch fix things so that -DHAVE_SYS_STAT_H=0 need not be added to tools.ini? If not, what problems do you observe? With the patch, do you see warnings when compiling? Does compiling with -D_CRT_SECURE_NO_WARNINGS cut down on the number of warnings? What's in your tools.ini file for building tzcode?

2 3

Re: Iana build failures on Windows
by Paul Eggert Dec. 17, 2024

Dec. 17, 2024

On 2024-12-15 23:11, Manuela Friedrich wrote: > localtime.c > d:\devsrc\treasure_test\iana\tmp\private.h(872): warning C4005: 'max': > macro redefinition > C:\Program Files (x86)\Windows > Kits\10\include\10.0.16299.0\ucrt\stdlib.h(1300): note: see previous > definition of 'max' > d:\devsrc\treasure_test\iana\tmp\private.h(873): warning C4005: 'min': > macro redefinition > C:\Program Files (x86)\Windows > Kits\10\include\10.0.16299.0\ucrt\stdlib.h(1301): note: see previous > definition of 'min' > localtime.c(418): error C2065: 'utc': undeclared identifier > localtime.c(418): warning C4047: ':': 'const char *' differs in levels of > indirection from 'int' > localtime.c(1449): error C2065: 'utc': undeclared identifier > localtime.c(1449): warning C4047: 'function': 'const char *' differs in > levels of indirection from 'int' > localtime.c(1449): warning C4024: 'strcpy': different types for formal and > actual parameter 2 > NMAKE : U1077: '"C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64\cl.EXE"' > : return code '0x2' Thanks for reporting these build glitches on MS-Windows. I installed the attached patches; please give them a try, as I don't use that platform.

1 0

Daylight Saving in the news
by Arthur Olson Dec. 15, 2024

Dec. 15, 2024

"Trump vows to end 'very costly' daylight saving time" (While Mexico may not pay for it, Mexico and Canada may follow suit.) https://www.bbc.com/news/articles/cn9gjvgv4neo @dashdashado

3 4

How permanent daylight saving time or permanent standard time would affect the USA
by Jonathan Leffler Dec. 13, 2024

Dec. 13, 2024

Article in the Washington Post about how early or late you would be in the dark if the USA adopted permanent daylight saving time or permanent standard time (compared with now). https://www.washingtonpost.com/nation/interactive/2024/no-daylight-saving-t… With decent interactive graphics. I'm a subscriber; I don't know if there's a paywall in place. -- 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."

12 16

[PROPOSED] Fix asctime.o, strftime.o dependencies
by Paul Eggert Dec. 11, 2024

Dec. 11, 2024

* Makefile (asctime.o): Don’t depend on tzfile.h. (strftime.o): Depend on tzdir.h, as it’s included indirectly via localtime.c if MKTIME_MIGHT_OVERFLOW. --- Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 2aafdc24..8faab6ff 100644 --- a/Makefile +++ b/Makefile @@ -1355,11 +1355,11 @@ long-long.ck unsigned.ck: $(VERSION_DEPS) zonenames: tzdata.zi @$(AWK) '/^Z/ { print $$2 } /^L/ { print $$3 }' tzdata.zi -asctime.o: private.h tzfile.h +asctime.o: private.h date.o: private.h difftime.o: private.h -localtime.o: private.h tzfile.h tzdir.h -strftime.o: localtime.c private.h tzfile.h +localtime.o: private.h tzdir.h tzfile.h +strftime.o: localtime.c private.h tzdir.h tzfile.h zdump.o: version.h zic.o: private.h tzfile.h tzdir.h version.h -- 2.47.1

1 0

[PROPOSED] Fix to2050.tzs timestamp in distributed tarball
by Paul Eggert Dec. 11, 2024

Dec. 11, 2024

* Makefile (TZS_DEPS): Remove asctime.c and add localtime.c. --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 5473dedd..2aafdc24 100644 --- a/Makefile +++ b/Makefile @@ -615,8 +615,8 @@ TZS_YEAR= 2050 TZS_CUTOFF_FLAG= -c $(TZS_YEAR) TZS= to$(TZS_YEAR).tzs TZS_NEW= to$(TZS_YEAR)new.tzs -TZS_DEPS= $(YDATA) asctime.c localtime.c \ - private.h tzfile.h zdump.c zic.c +TZS_DEPS= $(YDATA) localtime.c private.h \ + strftime.c tzfile.h zdump.c zic.c TZDATA_DIST = $(COMMON) $(DATA) $(MISC) # EIGHT_YARDS is just a yard short of the whole ENCHILADA. EIGHT_YARDS = $(TZDATA_DIST) $(DOCS) $(SOURCES) tzdata.zi -- 2.47.1

1 0

Add ICU's Etc/Unknown Zone to IANA Time Zone Database?
by Justin Grant Dec. 11, 2024

Dec. 11, 2024

Hi TZ friends - Should the time zone identifier "Etc/Unknown" (standardized in Unicode Technical Standard 35 and used by the ICU <https://icu.unicode.org/> library that implements time zone support in all major web browsers, in Java, and in other platforms) be added to the IANA Time Zone Database? Etc/Unknown would behave the same as the existing time zone identifier "Factory". Ideally, Etc/Unknown could be a Zone and Factory could be turned into a Link pointing to Etc/Unknown, because both of them have the meaning of "the time zone of this computer is not known" but Etc/Unknown is more self-describing and is better aligned with modern Zone naming conventions. Here's more context: "Etc/Unknown" is standardized in https://unicode.org/reports/tr35/#Time_Zone_Identifiers. Here's the relevant text from the standard: > There is a special code "unk" for an Unknown or Invalid time zone. > This can be expressed in the tz database style ID "Etc/Unknown", > although it is not defined in the tz database. Following this standard, Etc/Unknown is returned by ICU <https://icu.unicode.org/> when the time zone of a computer cannot be determined. Here's an example of an ICU method that can return Etc/Unknown: icu::TimeZone::detectHostTimeZone() <https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/classicu_1_1TimeZon…> . The fact that Etc/Unknown looks like an IANA identifier but is not actually in TZDB has been a long-running source of problems. Most recently, this week Chrome is rushing out a patch <https://issues.chromium.org/issues/381620359> that reverted a recent change that added support for the "Factory" zone by making it an alias for "Etc/Unknown". GIven that ICU previously didn't recognize Factory and so returned Etc/Unknown for computers in the Factory zone, this was assumed by everyone to be a safe change. But this change turned out to break some 3rd-party libraries and had to be reverted. After discussing this recent bug with engineers at Google, our consensus was that it'd be helpful for the time zone ecosystem if Etc/Unknown stopped being a special case and started being a regular Zone in the IANA Time Zone database. Especially if we could Link-ify Factory at the same time so that Zone picker UIs won't have two distinct "I don't know what time zone this is" choices. Thanks for considering this proposal. Best, Justin Grant

10 28

[PROPOSED] Fix unlikely multithreaded file descriptor leak
by Paul Eggert Dec. 9, 2024

Dec. 9, 2024

On multithreaded platforms, tzset could leak a file descriptor into a forked or execed process. Fix the leak. While we’re at it, don’t let the TZif file become the controlling tty. * NEWS: Mention this. * localtime.c (O_CLOEXEC, O_CLOFORK, O_IGNORE_CTTY, O_NOCTTY): Default to 0. (tzloadbody): Use these flags when opening the TZif file. --- NEWS | 5 +++++ localtime.c | 22 +++++++++++++++++----- 2 files changed, 22 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index 79686147..2fc7bb19 100644 --- a/NEWS +++ b/NEWS @@ -56,6 +56,11 @@ Unreleased, experimental changes PTRDIFF_MAX, a limit forced by C anyway; formerly tzcode silently misbehaved unless TZNAME_MAXIMUM was less than INT_MAX. + tzset and related functions no longer leak a file descriptor if + another thread forks or execs at about the same time and if the + platform has O_CLOFORK and O_CLOEXEC respectively. Also, the + functions no longer let a TZif file become a controlling terminal. + Changes to documentation The name Etc/Unknown is now reserved: it will not be used by TZDB. diff --git a/localtime.c b/localtime.c index 492965d9..f92676c6 100644 --- a/localtime.c +++ b/localtime.c @@ -96,12 +96,23 @@ typedef intmax_t timex_t; # define TZ_ABBR_ERR_CHAR '_' #endif /* !defined TZ_ABBR_ERR_CHAR */ -/* -** Support non-POSIX platforms that distinguish between text and binary files. -*/ +/* Port to platforms that lack some O_* flags. Unless otherwise + specified, the flags are standardized by POSIX. */ #ifndef O_BINARY -# define O_BINARY 0 +# define O_BINARY 0 /* MS-Windows */ +#endif +#ifndef O_CLOEXEC +# define O_CLOEXEC 0 +#endif +#ifndef O_CLOFORK +# define O_CLOFORK 0 +#endif +#ifndef O_IGNORE_CTTY +# define O_IGNORE_CTTY 0 /* GNU/Hurd */ +#endif +#ifndef O_NOCTTY +# define O_NOCTTY 0 #endif #ifndef WILDABBR @@ -542,7 +553,8 @@ tzloadbody(char const *name, struct state *sp, bool doextend, } if (doaccess && access(name, R_OK) != 0) return errno; - fid = open(name, O_RDONLY | O_BINARY); + fid = open(name, (O_RDONLY | O_BINARY | O_CLOEXEC | O_CLOFORK + | O_IGNORE_CTTY | O_NOCTTY)); if (fid < 0) return errno; -- 2.47.0

1 0

US Department of Transportation map of US timezones
by Roozbeh Pournader Dec. 7, 2024

Dec. 7, 2024

I just found out through https://x.com/RedistrictNet/status/1863742503242875046 That the US Department of Transportation has just rolled out an official map of US timezones. It's supposed to be at: https://geodata.bts.gov/datasets/usdot::time-zones/about (It doesn't load for me at the moment, possibly due to high demand.) Roozbeh

11 12