On 2026-07-19 04:41 AM, James Bellaire via tz wrote:
On 7/19/2026 3:32 AM, Paul Eggert via tz wrote:
On 2026-07-18 13:03, Guy Harris via tz wrote:
And encourage developers to 1) not rely on "EST" in a string meaning
UTC-05 etc., 2) stop using "EST" etc. in time stamp strings and
switch to UTC±N,
Good advice, and it suggests that if the US changes go through as
proposed, TZDB should follow Robert's suggestion[1] and switch North
American time zone abbreviations from the (A|E|C|M|P|AK)(D|S)T
abbreviation family to numeric abbreviations like "-04". This would
help avoid collision with longstanding practice that includes both
standards like Internet RFC 5322 and software packages galore. And
we'd be following our own advice to not generate abbreviations like
"EST".
Perhaps eventually common practice would become clear and we could
start using alphabetic abbreviations again. Until things settle down,
though, numeric abbreviations would likely cause fewer problems than
alphabetic ones.
The suggestion is to use numeric abbreviations such as "-04"? One
might as well set it at %z.
I believe the FORMAT field in the current form has value. My option is
that the FORMAT field should be maintained as a "best effort" name for
how people in that zone refer to their time.
If one wants to get wild we could use USET, USCT, USMT, USPT, USAK,
USHI, USAZ, USPR, USAT (for America/Thule's Atlantic Time). Canada can
have CAEST/CAEDT, CACST/CACDT, CAMST/CAMDT, CAPT ... wherever those
zones end up.
What would break is using America/Puerto_Rico and America/Phoenix in
Canada and expecting the FORMAT to be correct. So we're back to "AST"
and figure out something for America/Thule if the US goes permanent DST.
I manually made the following experimental modifications to
America/New_York in the northamerica source file:
# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
....
Rule US 2007 2027 - Mar Sun>=8 2:00 1:00 D
Rule US 2007 2027 - Nov Sun>=1 2:00 0 S
# Zone NAME STDOFF RULES FORMAT [UNTIL]
#STDOFF -4:56:01.6
Zone America/New_York -4:56:02 - LMT 1883 Nov 18 17:00u
-5:00 US E%sT 1920
-5:00 NYC E%sT 1942
-5:00 US E%sT 1946
-5:00 NYC E%sT 1967
-5:00 US E%sT 2027 Mar 14 2:00
-4:00 - -04
I then Generated a set of tzIF files using my adapted version of zic.
And then ran my adapted version of zdump, which output the two last
transitions as:
[217]
1793512799 2026-11-01 01:59:59 isdst 1 gmtoff -14400 stdoff -14400 EDT
1793512800 2026-11-01 01:00:00 isdst 0 gmtoff -18000 stdoff -14400 EST
1793512801 2026-11-01 01:00:01 isdst 0 gmtoff -18000 stdoff -14400 EST
[218]
1805007599 2027-03-14 01:59:59 isdst 0 gmtoff -18000 stdoff -14400 EST
1805007600 2027-03-14 03:00:00 isdst 0 gmtoff -14400 stdoff -14400 -04
1805007601 2027-03-14 03:00:01 isdst 0 gmtoff -14400 stdoff -14400 -04
So, those source changes work correctly without any modification to my
zic or zdump code.
My opinion this morning (which could change by midday) is that this is
the best way to do it.
I appreciate the idea of maintaining FORMAT. Paul has suggested
restoring EST sometime later. But I think we should dispense with that.
The main point of FORMAT, as I understand it, was to keep POSIX
abbreviations happy. But that convention originated decades ago when
POSIX time (UNIX time), and TzDb (Olson) was primarily directed to
support USA time zones. This has led to TzDb inventing all sorts of
versions of FORMAT to follow this tradition. This has worked OK for
years. But POSIX seems happy enough with FORMAT such as "-04". I think
that approach makes more sense going forward. I expect to hear other
opinions. Of course we can't change those that exist.
I've only tested America/New_York so I suppose there could be
complications in other time zones. Any approach will require updating
CLDR and downstream distributions. And it's likely to set off changes in
Mexico, Canada, EU, etc which will then need to be accommodated.
I hope the Senate does not pass the Sunshine Protection Act.
