On 12/6/23 11:18, Greg Wooledge wrote:
On Wed, Dec 06, 2023 at 10:44:42AM -0500, Pocket wrote:
Well POSIX has worked for me since the days of Xenix and System V.
Well, most of the goofy time zone changes were all *before* that. But
there's at least one that happened more recently....
unicorn:~$ TZ=EST5EDT date -d '2006-03-12 +4 hours'
Sun Mar 12 04:00:00 EST 2006
unicorn:~$ TZ=EST5EDT date -d '2007-03-11 +4 hours'
Sun Mar 11 05:00:00 EDT 2007
So, OK, I guess the EST5EDT time zone in Debian 12 properly handles
the change to start of DST in the US in 2007 (and more specifically,
handles dates *older* than that using the historic rules instead of
the current rules).
Looking at other periods of interest from Wikipedia:
unicorn:~$ TZ=EST5EDT date -d '1987-04-05 +4 hours'
Sun Apr 5 05:00:00 EDT 1987
unicorn:~$ TZ=EST5EDT date -d '1974-01-06 +4 hours'
Sun Jan 6 05:00:00 EDT 1974
unicorn:~$ TZ=EST5EDT date -d '1967-04-30 +4 hours'
Sun Apr 30 05:00:00 EDT 1967
I guess EST5EDT in Debian 12 is more like a synonym for America/New_York
than a real historical EST5EDT as described by Erik Naggum
<https://naggum.no/lugm-time.html>.
If this is satisfactory, then you can continue using the legacy time
zone without running into problems. At least on current Debian systems.
I wouldn't know how well-behaved that time zone is on other systems.
I used POSIX time zones on other systems including my custom scratch
built ones.
The custom built systems was built using a cross compiler for the AMD64,
aarch64 and armv7a platforms.
Never had an issue.
Don't see what the issue is here?
Honestly, I don't see the appeal of using legacy time zone names. Is
it just for the sake of contrariness?
diff /usr/share/zoneinfo/EST5EDT /usr/share/zoneinfo/America/New_York
Binary files /usr/share/zoneinfo/EST5EDT and
/usr/share/zoneinfo/America/New_York differ
Because I can ;}
--
It's not easy to be me
