in the docs (thanks for hiding them & doing away with manpages) it says: -------
To make the DHCP server in the Debian package isc-dhcp-server send NTP
server
information, add a line like the following at an appropriate place:
option ntp-servers ntp1.foo.bar, ntp2.foo.bar;
----------
Greetings all;
in the docs (thanks for hiding them & doing away with manpages) it says: -------
To make the DHCP server in the Debian package isc-dhcp-server send NTP
server
information, add a line like the following at an appropriate place:
option ntp-servers ntp1.foo.bar, ntp2.foo.bar;
----------
now I assume the foo.bar is to be replaced by something unique [...]
I'm not sure that is correct. According to RFC 2132, Section 8.3, the
NTP time server source option is IP addresses, not hostnames. That
means ISC DHCP docs need to say it resolves a hostname to an IP, or it
needs to tell people to use IP addresses in accordance with the RFC.
See <https://datatracker.ietf.org/doc/html/rfc2132#section-8.3>.
If you try that [using a hostname in NTP server option] with the ISC's
KEA DHCP (KEA is ISC's rewrite of the old DHCP server), then the
server fails to start. You must use an IP address for NTP server
option with KEA DHCP.
On 4/12/23 08:51, jeremy ardley wrote:
|ntpq -p timedatectl status chronyc sources or if you are hardcore
sudo tcpdump -i any port 123 |||||
Sorry, something screwed up the list
One or more of:
ntpq -p
timedatectl status
chronyc sources
or if you are hardcore
sudo tcpdump -i any port 123
.
On Sun, Dec 03, 2023 at 07:42:42PM -0500, gene heskett wrote:
Greetings all;
in the docs (thanks for hiding them & doing away with manpages) it says:
-------
To make the DHCP server in the Debian package isc-dhcp-server send NTP
server
information, add a line like the following at an appropriate place:
option ntp-servers ntp1.foo.bar, ntp2.foo.bar;
----------
now I assume the foo.bar is to be replaced by something unique [...]
The whole thing is supposed to be a resolvable host name for your client, i.e. either something your client can look up in the DNS, something in
its /etc/hosts, possibly even a naked IP address will do. It's quite
likely the request goes through the resolver (which, BTW, has a man page).
Cheers
timedatectl status
On 12/3/23 20:06, jeremy ardley wrote:
On 4/12/23 08:51, jeremy ardley wrote:
|ntpq -p timedatectl status chronyc sources or if you are hardcore
sudo tcpdump -i any port 123 |||||
Sorry, something screwed up the list
One or more of:
ntpq -p
timedatectl status
chronyc sources
or if you are hardcore
sudo tcpdump -i any port 123
This latter, disclosed that I was serving as a lower accuracy ntp
server to anybody that came calling, probably serving a hundred or
more clients in around 4 hours logging. I am surprised that dd-wrt
lets port 123 thru from the network unhindered.
I have this printer getting its time info from this machine's ntpsec
but the chrony in the printer is ignoring /etc/timezone, stuck in PST
or 4 hours behind me when comparing the output of "date". Except for
the hour, its dead on to the second.
This printer is running armbian buster, with apt using the debian arm
repos, which have long been disabled, so I'm stuck editing what it
has. There are not enough tools to build a tarball either.
That messes with the estimates of time the print will finish. Chrony
in the printer says its a full blown ISC client, but its ignoring the contents of /etc/timezone. Or something else is overriding /etc/timezone.
Does anyone know of an override to that I might check?
Thanks all
ntpq -pI don't have that on the printer, it is running chrony.
On 12/4/23 05:03, Anssi Saari wrote:
timedatectl timesync-statusroot@mkspi:/etc# timedatectl timesync-status
Failed to query server: Connection timed out
This printer is running chrony, which removes timesyncd.
ntpsec on this machine is working, even the seconds match and the log shows the request being serviced:
06:19:05.847872 eno1 In IP mkspi.coyote.den.48265 > coyote.coyote.den.ntp: NTPv4, Client, length 48
06:19:05.848004 eno1 Out IP coyote.coyote.den.ntp > mkspi.coyote.den.48265: NTPv4, Server, length 48
but the printer is on PST where I'm on EST, 4 hours difference and the printer is ignoring /etc/timezone. Why? What can override it?
timedatectl timesync-statusroot@mkspi:/etc# timedatectl timesync-status
On 12/4/23 05:55, Pocket wrote:
ntpq -pI don't have that on the printer, it is running chrony.
On 12/4/23 03:58, gene heskett wrote:
I have this printer getting its time info from this machine's ntpsec but the chrony in the printer is ignoring /etc/timezone, stuck in PST or 4 hours behind me when comparing the output of "date".
What does /etc/localtime say?
For example on my raspberrypi 4
ls -hal /etc/localtime
lrwxrwxrwx 1 root root 27 Nov 1 18:21 /etc/localtime -> /usr/share/zoneinfo/EST5EDT
cat /etc/timezone
America/New_York
On Mon, Dec 04, 2023 at 05:55:25AM -0500, Pocket wrote:
On 12/4/23 03:58, gene heskett wrote:According to <https://wiki.debian.org/TimeZoneChanges> the correct
I have this printer getting its time info from this machine's ntpsec but >>> the chrony in the printer is ignoring /etc/timezone, stuck in PST or 4What does /etc/localtime say?
hours behind me when comparing the output of "date".
For example on my raspberrypi 4
ls -hal /etc/localtime
lrwxrwxrwx 1 root root 27 Nov 1 18:21 /etc/localtime ->
/usr/share/zoneinfo/EST5EDT
cat /etc/timezone
America/New_York
way to set the time zone in Debian is to run "dpkg-reconfigure tzdata"
which will update both /etc/timezone *and* /etc/localtime. Of course,
since Gene's printer isn't running Debian, we can't accurately tell
him what commands to run.
But at the bare minimum, Gene should check:
ls -ld /etc/*time*
If it turns out his printer has an /etc/localtime symlink pointing
to the wrong time zone, then re-pointing it should help.
On Mon, Dec 04, 2023 at 06:32:38AM -0500, gene heskett wrote:
On 12/4/23 05:55, Pocket wrote:
ntpq -pI don't have that on the printer, it is running chrony.
A quick Google search for "chrony equivalent of ntpq" gives me <https://karloluiten.nl/chrony-status-command-ntpq-p-alternative/>
which says to use "chronyc sources" or "chronyc tracking".
[...]
So here on coyote: date -u:
Mon Dec 4 15:47:44 UTC 2023
but on mkspi: date -u:
Mon 04 Dec 2023 03:47:16 PM UTC
[...]
WTH? Where is that false 12 hour offset coming from?
root@mkspi:/etc# chronyc sources
210 Number of sources = 1
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* coyote.coyote.den 2 6 17 42 -22us[ -25us] +/-
41ms
root@mkspi:/etc# date
Mon 04 Dec 2023 07:34:59 AM PST
its 10:35 here, still 3 hours off.
So here on coyote: date -u:
Mon Dec 4 15:47:44 UTC 2023
but on mkspi: date -u:
Mon 04 Dec 2023 03:47:16 PM UTC
WTH? Where is that false 12 hour offset coming from?
Thats says this machine has it hdware clock on utc.
Mon Dec 4 15:47:44 UTC 2023
Mon 04 Dec 2023 03:47:16 PM UTC
WTH? Where is that false 12 hour offset coming from?
On 04/12/2023 23:34, Greg Wooledge wrote:
WTH? Where is that false 12 hour offset coming from?There is no 12 hour offset. One is being reported in 24-hour time, and
the other in 12-hour time (it says "PM"), because of different locale definitions.
dpkg-reconfigure locales
Or its equivalent for modified armbian. See /etc/default/locale and https://www.debian.org/doc/manuals/debian-reference/ch09.en.html#_customized_display_of_time_and_date
"9.3.4. Customized display of time and date" and "9.5.5. System and hardware time".
I hope, no applications rely on specific locale while parsing time or numbers.
echo "$TZ"
https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
but ignore most of its content, use zone identifiers like America/New_York
On Mon, Dec 04, 2023 at 06:32:38AM -0500, gene heskett wrote:
On 12/4/23 05:55, Pocket wrote:
ntpq -pI don't have that on the printer, it is running chrony.
A quick Google search for "chrony equivalent of ntpq" gives me <https://karloluiten.nl/chrony-status-command-ntpq-p-alternative/>
which says to use "chronyc sources" or "chronyc tracking".
ls -hal /etc/localtime
On 12/4/23 07:17, Greg Wooledge wrote:
ls -hal /etc/localtime
Aha! You found it, but how do I change it?
root@mkspi:/etc# cat timezone
America/New_York
root@mkspi:/etc# ls -hal /etc/localtime
lrwxrwxrwx 1 root root 39 Jul 25 2022 /etc/localtime -> /usr/share/zoneinfo/America/Los_Angeles
use mc to edit the /etc/localtime link? Surely there is better way...
The string as the last few
bytes of posixrules looks correct at EST5EDT, and I've got a headache.
there are links to links to links in that midden heap.
On Mon, Dec 04, 2023 at 10:55:47AM -0500, gene heskett wrote:
root@mkspi:/etc# chronyc sources
210 Number of sources = 1
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* coyote.coyote.den 2 6 17 42 -22us[ -25us] +/-
41ms
I've never used chrony, but that looks good at first glance.
root@mkspi:/etc# date
Mon 04 Dec 2023 07:34:59 AM PST
its 10:35 here, still 3 hours off.
The time is *correct*, it's just being reported for a different time
zone than you want.
So here on coyote: date -u:
Mon Dec 4 15:47:44 UTC 2023
but on mkspi: date -u:
Mon 04 Dec 2023 03:47:16 PM UTC
Again, both correct.
WTH? Where is that false 12 hour offset coming from?
There is no 12 hour offset. One is being reported in 24-hour time, and
the other in 12-hour time (it says "PM"), because of different locale definitions.
All you need to do is change your system's default time zone, which on
Debian involves changing the *file* /etc/timezone and the *symlink* /etc/localtime. Both are required, because some programs use one and
some use the other.
We've said this in like 3 other emails so far.
.
On Dec 04, 2023, gene heskett wrote:It might well be, Dan but no man page, Set for "C" in the env output.
[...]
So here on coyote: date -u:
Mon Dec 4 15:47:44 UTC 2023
but on mkspi: date -u:
Mon 04 Dec 2023 03:47:16 PM UTC
[...]
WTH? Where is that false 12 hour offset coming from?
Coyote seems to use the standard output of 'date' (in 24-hour clock
format).
mkspi /appears/ to be using an approximation of "-R" ("--rfc-email",
as set in RFC5322), though it's missing the comma between "Mon" and "04
Dec", and is set in 12-hour mode.
It's been ages since I've dug into it, but I _BELIEVE_ the LC_TIME environment variable has an effect here. (Or had, at some point in the
past).
On Mon, Dec 04, 2023 at 02:11:51PM -0500, gene heskett wrote:as reported, its now fixed.
That leave the localtime error pretty much up to the date command, or is
there something else screwing with this? Where ALL in this chain does
/etc/timezone get used, which is currently set to:
America/New_York
ls -ld /etc/*time*
Please.
.
Gene writes:
Thats says this machine has it hdware clock on utc.
No. That says that the system clock (not the hardware clock) is
synchronized to NTP time. The system clock keeps UNIX time: seconds
since the epoch. It is converted to either UTC or local time as
approporiate for display. It says nothing about the hardware clock.
Try
hwclock -l
to find out what timezone the hardwareclock is set to.
If the box is running systemd try
timedatectl
I classify time zone names into three historic eras. In the oldest era,
you have zone names like EST5EDT which are composed of three pieces.
The first piece, EST, is the zone's name when the clock is "normal" (not daylight saving or summer time). The second piece, 5, is the number
of hours behind GMT the clock is (normally). The third piece, EDT, is
the zone's name when daylight saving time is in effect.
In the second era, zone names look like "US/Eastern". The piece on the
right hand side is a component of the piece on the left. I'm uncertain whether the pieces on the left are always country codes, or if there's
some other arrangement.
In the modern era, zone names look like "America/Chicago". The piece on
the left is a continent (or other large geographic region, e.g. "Pacific"), and the piece on the right is a major city, preferably *the* major city, which exemplifies the specific time zone in question.
For you and me, the current era time zone name is "America/New_York".
This is how the Debian installer sets the localtime symlink, and is
what we should be using if we have to set it ourselves.
I personally find "US/Eastern" the easiest to grasp, and I'm sad that
this pattern fell out of fashion, for whatever reason. Whenever I tell people on the Internet (who may not be Linux users) what time zone I'm
in, I always go with "US/Eastern". It's just so *clear*.
On 12/4/23 07:17, Greg Wooledge wrote:
ls -hal /etc/localtime
lrwxrwxrwx 1 root root 27 Nov 1 18:21 /etc/localtime ->
/usr/share/zoneinfo/EST5EDT
And using mc to edit that link fixed it, I am now getting the correct
time from date, thank you a lot.
But maybe a bug against tzselect s/b filed, IMNSHO it should have
fixed that. It did not.
Cheers, Gene Heskett.
On 12/4/23 11:31, Dan Purgert wrote:
On Dec 04, 2023, gene heskett wrote:
[...]
So here on coyote: date -u:
Mon Dec 4 15:47:44 UTC 2023
but on mkspi: date -u:
Mon 04 Dec 2023 03:47:16 PM UTC
[...]
WTH? Where is that false 12 hour offset coming from?
Coyote seems to use the standard output of 'date' (in 24-hour clock format).
mkspi /appears/ to be using an approximation of "-R" ("--rfc-email",
as set in RFC5322), though it's missing the comma between "Mon" and "04 Dec", and is set in 12-hour mode.
It's been ages since I've dug into it, but I _BELIEVE_ the LC_TIME environment variable has an effect here. (Or had, at some point in the past).It might well be, Dan but no man page,
I redirected the /etc/localtime link to EST5EDT and fixed it, the
thing thought it was in the 3rd worst hell hole in the US, LA, CA.
On 05/12/2023 05:14, Pocket wrote:
For[...]
gene..................................................................
zone=EST5EDT
zoneinfo=/usr/share/zoneinfo
localtime=/etc/localtime
timezone=/etc/timezone
profile=/etc/profile.d
if [ -e "$zoneinfo"/"$zone" ];then
ln -sf "$zoneinfo"/"$zone" "$localtime"
else
printf "%s\n" "Invalid zone: $zoneinfo/$zone"
exit 1
fi
printf "%s\n" "$zone" > "$timezone"
printf "%s\n" "TZ=$zone;export TZ" > "$profile"/timezone.sh
To set /etc/localtime and /etc/timezone I would recommend the command
that has been repeated several times in this thread:
dpkg-reconfigure tzdata
And I would recommend against setting the TZ environment variable
unless it is really necessary. If somebody needs it then it is better
to do it in /etc/environment.d as well. KDE has its own GUI to set user-specific timezone, but I am unsure if selected value will be
applied in the case of console or ssh login.
I am surprised that POSIX EST5EDT timezone has irregularities at least
as it is implemented in GNU libc. I believed that it specifies just
standard and summer time.
LANG=C.UTF-8 TZ=EST5EDT date -d 'TZ="Z" 1940-01-01 00:00'
Sun Dec 31 19:00:00 EST 1939
LANG=C.UTF-8 TZ=EST5EDT date -d 'TZ="Z" 1943-01-01 00:00'
Thu Dec 31 20:00:00 EWT 1942
However since these rules are specific to US, I would prefer IANA
identifiers like America/New_York.
https://naggum.no/lugm-time.html
Erik Naggum. A Long, Painful History of Time. 1999
8.2 Timezone Representation
David Olsen of Digital Equipment Corporation has laid down a tremendous
amount of work in collecting the timezones of the world and their
daylight saving time boundaries. Contrary to the Unix System V approach
from New Jersey (insert appropriate booing for best effect), which
codifies a daylight saving time regime only for the current year, and
apply it to all years, David Olsen's approach is to maintain tables of
all the timezone changes.
On 12/5/23 11:38, Max Nikulin wrote:
That was not tried.
On 05/12/2023 05:14, Pocket wrote:
For[...]
gene..................................................................
zone=EST5EDT
zoneinfo=/usr/share/zoneinfo
localtime=/etc/localtime
timezone=/etc/timezone
profile=/etc/profile.d
if [ -e "$zoneinfo"/"$zone" ];then
ln -sf "$zoneinfo"/"$zone" "$localtime"
else
printf "%s\n" "Invalid zone: $zoneinfo/$zone"
exit 1
fi
printf "%s\n" "$zone" > "$timezone"
printf "%s\n" "TZ=$zone;export TZ" > "$profile"/timezone.sh
To set /etc/localtime and /etc/timezone I would recommend the command
that has been repeated several times in this thread:
dpkg-reconfigure tzdata
And I would recommend against setting the TZ environment variableBoth America/New_York and the ESTSEDT methods are available on this
unless it is really necessary. If somebody needs it then it is better
to do it in /etc/environment.d as well. KDE has its own GUI to set
user-specific timezone, but I am unsure if selected value will be
applied in the case of console or ssh login.
I am surprised that POSIX EST5EDT timezone has irregularities at
least as it is implemented in GNU libc. I believed that it specifies
just standard and summer time.
elderly buster install. tzselect outputs the America/ version.
In retrospect, I think making /etc/localtime a link to /etc/timezone
would probably have made this endless thread moot. That would work
until some update which will never happen now, deletes /etc/timezone.
The education of Gene continues... I've learned a lot. Thank you all.
Cheers, Gene Heskett.
On 05/12/2023 05:14, Pocket wrote:
For[...]
gene..................................................................
zone=EST5EDT
zoneinfo=/usr/share/zoneinfo
localtime=/etc/localtime
timezone=/etc/timezone
profile=/etc/profile.d
if [ -e "$zoneinfo"/"$zone" ];then
ln -sf "$zoneinfo"/"$zone" "$localtime"
else
printf "%s\n" "Invalid zone: $zoneinfo/$zone"
exit 1
fi
printf "%s\n" "$zone" > "$timezone"
printf "%s\n" "TZ=$zone;export TZ" > "$profile"/timezone.sh
To set /etc/localtime and /etc/timezone I would recommend the command
that has been repeated several times in this thread:
dpkg-reconfigure tzdata
And I would recommend against setting the TZ environment variable unless
it is really necessary. If somebody needs it then it is better to do it
in /etc/environment.d as well. KDE has its own GUI to set user-specific timezone, but I am unsure if selected value will be applied in the case
of console or ssh login.
I am surprised that POSIX EST5EDT timezone has irregularities at least
as it is implemented in GNU libc. I believed that it specifies just
standard and summer time.
On 05/12/2023 05:14, Pocket wrote:
For gene..................................................................[...]
zone=EST5EDT
zoneinfo=/usr/share/zoneinfo
localtime=/etc/localtime
timezone=/etc/timezone
profile=/etc/profile.d
if [ -e "$zoneinfo"/"$zone" ];then
ln -sf "$zoneinfo"/"$zone" "$localtime"
else
printf "%s\n" "Invalid zone: $zoneinfo/$zone"
exit 1
fi
printf "%s\n" "$zone" > "$timezone"
printf "%s\n" "TZ=$zone;export TZ" > "$profile"/timezone.sh
To set /etc/localtime and /etc/timezone I would recommend the command
that has been repeated several times in this thread:
dpkg-reconfigure tzdata
And I would recommend against setting the TZ environment variable
unless it is really necessary. If somebody needs it then it is better
to do it in /etc/environment.d as well. KDE has its own GUI to set user-specific timezone, but I am unsure if selected value will be
applied in the case of console or ssh login.
I am surprised that POSIX EST5EDT timezone has irregularities at least
as it is implemented in GNU libc. I believed that it specifies just
standard and summer time.
However since these rules are specific to US, I would prefer IANA
identifiers like America/New_York.
https://naggum.no/lugm-time.html
Erik Naggum. A Long, Painful History of Time. 1999
8.2 Timezone Representation
David Ols[o]n of Digital Equipment Corporation has laid down a tremendous amount of work in collecting the timezones of the world and their
daylight saving time boundaries. Contrary to the Unix System V approach from New Jersey (insert appropriate booing for best effect), which
codifies a daylight saving time regime only for the current year, and
apply it to all years, David Ols[o]n's approach is to maintain tables of all the timezone changes.
On 06/12/2023 00:03, Pocket wrote:
On 12/5/23 11:37, Max Nikulin wrote:
On 05/12/2023 05:14, Pocket wrote:
[...]For gene........................................................
dpkg-reconfigure tzdata
That does not work. Cannot set EST5EDT. you have to do that manually.
Do you have reasons to prefer EST5EDT to IANA identifiers like America/Detroit, America/New_York, etc. (that have some differences
from EST5EDT)? Location-based time zones should be more precise for
most of users.
I find it reasonable that "dpkg-reconfigure tzdata" forces users to
set a timezone that should provide more accurate results for them.
I have seen America/New_York in a couple of Gene's messages including https://lists.debian.org/msgid-search/7ba9b8bc-2929-4a3d-8007-a1b5c7f6fc16@shentel.net
so I assume it is one that he should use. My impression is that
EST5EDT appeared unintentionally.
I don't use KDE, I am using LXDE and systems without desktops.
Comment that part out of the shell script.
Do you really need TZ environment variable especially set to the value
in system-wide configuration? In the Gene's case I mentioned it for
the case that some piece of software decided to set it, but I have not recommended to set it. It is a way to make debugging of a next issue
harder.
Sorry, I do not have a VM with LXDE to check if TZ is actually set for applications. It may depend on display manager configuration and on
the approach to launch applications: window manager children or
systemd session.
Anyway I noticed "For gene" and I remember that he uses KDE that has a
GUI for it. However I am unsure if KDE is installed to this 3d printer controller.
Which is why I use it.
/usr/share/zoneinfo/posix/EST5EDT is a symlilnk to
/usr/share/zoneinfo/EST5EDT
And it is rather confusing since arbitrary abbreviations may be used
to specify POSIX time zones, e.g. ABC5DEF. From my point of view, it
is just legacy since the time zone database is available.
It was painful when JavaScript (ECMAScript 5) had fixed DST rules
based on current regulations. Chrome followed the standard, Firefox
used accurate history of time transitions. I have not checked POSIX,
but I see that GNU libc approach is something third in between.
Let's use time zones that allows to get accurate local time.
On 06/12/2023 20:08, Pocket wrote:
On 12/6/23 07:22, Max Nikulin wrote:[...]
On 06/12/2023 00:03, Pocket wrote:
On 12/5/23 11:37, Max Nikulin wrote:Do you have reasons to prefer EST5EDT to IANA identifiers like
dpkg-reconfigure tzdata
That does not work. Cannot set EST5EDT. you have to do that manually. >>>
America/Detroit, America/New_York, etc. (that have some differences
from EST5EDT)? Location-based time zones should be more precise for
most of users.
I follow POSIX
There are enough oversights in various standards. When accurate time
zone DB is unavailable, POSIX ones might be used (if risk to get wrong results is accepted). Otherwise, from my of view, it is a legacy to
keep aside and a kind of cargo cult. That is why I asked concerning
your reasons.
I introduced EST5DST to this by simply posted my configuration.
Maybe due to language barrier I perceived it as a recommendation for
Gene. The same time zone appeared earlier in a Gene's message. Perhaps
he still has it as the /etc/localtime link target. Of course, you are
free to have whatever you want in your configuration. Please, be
responsible suggesting anything to others.
[...]Do you really need TZ environment variable especially set to the
value in system-wide configuration?
I doesn't hurt anything, What if I install some application that uses
it and it is not set?
It may cause waste of time when you will need to change time zone. If
not all occurrences are updated you may see wrong time. For me it is a
reason to avoid unnecessary settings.
cat /etc/default/locale
LANG=POSIX
Does it set UTF-8 encoding? Sometimes I use C.UTF-8. However there are
enough subtle differences (sorting, etc.) from any en_* locale.
Well POSIX has worked for me since the days of Xenix and System V.
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.
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
Honestly, I don't see the appeal of using legacy time zone names. Is
it just for the sake of contrariness?
On 06/12/2023 12:22, David Wright wrote:
On Tue 05 Dec 2023 at 23:37:31 (+0700), Max Nikulin wrote:
I am surprised that POSIX EST5EDT timezone has irregularities at least
as it is implemented in GNU libc. I believed that it specifies just
standard and summer time.
During WWII they had War Time, just as Britain had Double Summer Time,
with Summer Time through the winters.
I was aware of special DST rules during WWII, but I did not expect
that "EST5EDT" may include any historical data. Certainly it does not explicitly specify days when summer time is effective, just
abbreviations "EST" and "EDT" with time offset of 5 hours behind UTC
for "EST". Partial time transition history is new for me for these
kind of time zones.
https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States
is a long enough article.
I don't know who maintains the legacy EST5EDT zone, or for whom;
the quotation below suggests that it may just follow New Jersey.
For a long period after the war, it seems the timezones in the US
were all over the place.
https://data.iana.org/time-zones/theory.html :
Older versions of this package defined legacy names that are[...]
incompatible with the first guideline of location names, but which are
still supported. These legacy names are mostly defined in the file
'etcetera'. Also, the file 'backward' defines the legacy names
'Etc/GMT0', 'Etc/GMT-0', 'Etc/GMT+0', 'GMT0', 'GMT-0' and 'GMT+0', and
the file 'northamerica' defines the legacy names 'EST5EDT', 'CST6CDT',
'MST7MDT', and 'PST8PDT'.
POSIX does not define the DST transitions for TZ values like "EST5EDT".
Traditionally the current US DST rules were used to interpret such
values, but this meant that the US DST rules were compiled into each
time conversion package, and when US time conversion rules changed (as
in the United States in 1987 and again in 2007), all packages that
interpreted TZ values had to be updated to ensure proper results.
My reading of this document is that EST5EDT file in tzdata is a POSIX extension, not "true" POSIX.
A lot of details concerning database contents are given if files like https://github.com/eggert/tz/blob/main/northamerica
I have not noticed any America/* timezone that strictly follows EST5EDT.
On Wed, Dec 06, 2023 at 12:06:04PM -0500, Pocket wrote:
From the READMEThe standards are determined by government entities. The question is
The information in the time zone data files is by no means authoritative;
fixes and enhancements are welcome. Please see the file CONTRIBUTING
for details
I take that as chaos reins supreme and one zone is no better or worst that >> the other(s)
IE there is no "standard"
how accurately a given time zone reflects the decisions made by the government entities within a given political space.
If America/New_York more accurately describes the tracking of political timekeeping within the Eastern part of the United States (with specific exceptions, e.g. Kentucky) than EST5EDT does, then America/New_York
should be preferred for most purposes.
From the README
The information in the time zone data files is by no means authoritative; fixes and enhancements are welcome. Please see the file CONTRIBUTING
for details
I take that as chaos reins supreme and one zone is no better or worst that the other(s)
IE there is no "standard"
My reading of this document is that EST5EDT file in tzdata is a POSIX extension, not "true" POSIX.
POSIX format specification
The POSIX time zone format is the traditionally used format for AIX systems and
provides a slight performance advantage over the Olson time zone format.
Example of a POSIX format is EST5EDT.
The advantage of POSIX is that you can easily and explicitly specify the time
zone and daylight saving time (DST) details manually, however you wish. The
performance of applications that call time functions will be faster than using
Olson specification. And whenever a nation's government decides to change its
DST rules, the POSIX format is simpler because we can simply change the
variable definition. There is no need to install any new patch to update time
database files, as Olson requires.
Does this apply to "us?"
https://developer.ibm.com/articles/au-aix-posix/
On Wed, Dec 06, 2023 at 05:40:00PM -0000, Curt wrote:
POSIX format specificationThis does *not* describe how Debian's EST5EDT, and similarly named
The POSIX time zone format is the traditionally used format for AIX systems and
provides a slight performance advantage over the Olson time zone format. >> Example of a POSIX format is EST5EDT.
The advantage of POSIX is that you can easily and explicitly specify the time
zone and daylight saving time (DST) details manually, however you wish. The
performance of applications that call time functions will be faster than using
Olson specification. And whenever a nation's government decides to change its
DST rules, the POSIX format is simpler because we can simply change the
variable definition. There is no need to install any new patch to update time
database files, as Olson requires.
Does this apply to "us?"
https://developer.ibm.com/articles/au-aix-posix/
zones, work. Debian's time zones use a database of DST transition
periods -- all of them, even EST5EDT. It's just a different set of transitions than America/New_York uses.
Also, you snipped the rest of that section:
The disadvantage of this approach is that it cannot track the history
of timezone-related changes and it is not easy to read as it looks
cryptic. When a government changes the rules and you update your time
zone (TZ) variable, it is assumed to be the same DST rule for all
years past and future.
That's a fairly important paragraph.
Applying the same rules to a timestamp in 2023 and a timestamp in 2006
may give incorrect results, as the DST rules in the US changed in 2007. That's why the method described by this AIX manual is no longer in
common use.
TZ=POSIX;date
Wed Dec 6 18:00:38 POSIX 2023
TZ=America/New_York;date
Wed Dec 6 13:00:21 EST 2023
TZ=EST5DST;date
Wed Dec 6 13:01:10 EST 2023
What is the problem?
On Wed, Dec 06, 2023 at 01:02:45PM -0500, Pocket wrote:
TZ=POSIX;date
Wed Dec 6 18:00:38 POSIX 2023
"POSIX" is not a valid timezone name in Debian 12. Therefore you're
just seeing UTC here. Giving an invalid TZ always gives you UTC, but
with whatever crazy-ass name you used echoed back at you, to give you
the illusion that your name was valid. It's a *huge* pitfall. I've been
bit by this myself.
TZ=America/New_York;date
Wed Dec 6 13:00:21 EST 2023
TZ=EST5DST;date
Wed Dec 6 13:01:10 EST 2023
What is the problem?
Gods DAMN it. I didn't want to have to dig through these stupid zone
dumps, but you're FORCING my hand.
unicorn:~$ zdump -v -c 1918,1950 EST5EDT
EST5EDT -9223372036854775808 = NULL
EST5EDT -9223372036854689408 = NULL
EST5EDT Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST isdst=0 gmtoff=-18000
EST5EDT Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT isdst=1 gmtoff=-14400
EST5EDT Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT isdst=1 gmtoff=-14400
EST5EDT Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST isdst=0 gmtoff=-18000
EST5EDT Sun Mar 30 06:59:59 1919 UT = Sun Mar 30 01:59:59 1919 EST isdst=0 gmtoff=-18000
EST5EDT Sun Mar 30 07:00:00 1919 UT = Sun Mar 30 03:00:00 1919 EDT isdst=1 gmtoff=-14400
EST5EDT Sun Oct 26 05:59:59 1919 UT = Sun Oct 26 01:59:59 1919 EDT isdst=1 gmtoff=-14400
EST5EDT Sun Oct 26 06:00:00 1919 UT = Sun Oct 26 01:00:00 1919 EST isdst=0 gmtoff=-18000
EST5EDT Mon Feb 9 06:59:59 1942 UT = Mon Feb 9 01:59:59 1942 EST isdst=0 gmtoff=-18000
EST5EDT Mon Feb 9 07:00:00 1942 UT = Mon Feb 9 03:00:00 1942 EWT isdst=1 gmtoff=-14400
EST5EDT Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 18:59:59 1945 EWT isdst=1 gmtoff=-14400
EST5EDT Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 19:00:00 1945 EPT isdst=1 gmtoff=-14400
EST5EDT Sun Sep 30 05:59:59 1945 UT = Sun Sep 30 01:59:59 1945 EPT isdst=1 gmtoff=-14400
EST5EDT Sun Sep 30 06:00:00 1945 UT = Sun Sep 30 01:00:00 1945 EST isdst=0 gmtoff=-18000
EST5EDT 9223372036854689407 = NULL
EST5EDT 9223372036854775807 = NULL
OK? There's dump number one. Now let's compare to dump number two:
unicorn:~$ zdump -v -c 1918,1950 America/New_York
America/New_York -9223372036854775808 = NULL
America/New_York -9223372036854689408 = NULL
America/New_York Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT isdst=1 gmtoff=-14400
America/New_York Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT isdst=1 gmtoff=-14400
America/New_York Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 30 06:59:59 1919 UT = Sun Mar 30 01:59:59 1919 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 30 07:00:00 1919 UT = Sun Mar 30 03:00:00 1919 EDT isdst=1 gmtoff=-14400
America/New_York Sun Oct 26 05:59:59 1919 UT = Sun Oct 26 01:59:59 1919 EDT isdst=1 gmtoff=-14400
America/New_York Sun Oct 26 06:00:00 1919 UT = Sun Oct 26 01:00:00 1919 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 28 06:59:59 1920 UT = Sun Mar 28 01:59:59 1920 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 28 07:00:00 1920 UT = Sun Mar 28 03:00:00 1920 EDT isdst=1 gmtoff=-14400
America/New_York Sun Oct 31 05:59:59 1920 UT = Sun Oct 31 01:59:59 1920 EDT isdst=1 gmtoff=-14400
America/New_York Sun Oct 31 06:00:00 1920 UT = Sun Oct 31 01:00:00 1920 EST isdst=0 gmtoff=-18000
[...]
I'm truncating this one because it's much longer. Apparently this one
shows every year, even if there are no DST rule changes that year. What
does this mean? Hell if I know.
From the README
The information in the time zone data files is by no means authoritative; fixes and enhancements are welcome. Please see the file CONTRIBUTING
for details
I take that as chaos reins supreme and one zone is no better or worst
that the other(s)
IE there is no "standard"
TZ=POSIX;date
Wed Dec 6 18:00:38 POSIX 2023
TZ=America/New_York;date
Wed Dec 6 13:00:21 EST 2023
TZ=EST5DST;date
Wed Dec 6 13:01:10 EST 2023
What is the problem?
On Dec 6, 2023, at 1:28 PM, Greg Wooledge <greg@wooledge.org> wrote:
On Wed, Dec 06, 2023 at 01:02:45PM -0500, Pocket wrote:
TZ=POSIX;date
Wed Dec 6 18:00:38 POSIX 2023
"POSIX" is not a valid timezone name in Debian 12. Therefore you're
just seeing UTC here. Giving an invalid TZ always gives you UTC, but
with whatever crazy-ass name you used echoed back at you, to give you
the illusion that your name was valid. It's a *huge* pitfall. I've been
bit by this myself.
TZ=America/New_York;date
Wed Dec 6 13:00:21 EST 2023
TZ=EST5DST;date
Wed Dec 6 13:01:10 EST 2023
What is the problem?
Gods DAMN it. I didn't want to have to dig through these stupid zone
dumps, but you're FORCING my hand.
unicorn:~$ zdump -v -c 1918,1950 EST5EDT
EST5EDT -9223372036854775808 = NULL
EST5EDT -9223372036854689408 = NULL
EST5EDT Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST isdst=0 gmtoff=-18000
EST5EDT Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT isdst=1 gmtoff=-14400
EST5EDT Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT isdst=1 gmtoff=-14400
EST5EDT Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST isdst=0 gmtoff=-18000
EST5EDT Sun Mar 30 06:59:59 1919 UT = Sun Mar 30 01:59:59 1919 EST isdst=0 gmtoff=-18000
EST5EDT Sun Mar 30 07:00:00 1919 UT = Sun Mar 30 03:00:00 1919 EDT isdst=1 gmtoff=-14400
EST5EDT Sun Oct 26 05:59:59 1919 UT = Sun Oct 26 01:59:59 1919 EDT isdst=1 gmtoff=-14400
EST5EDT Sun Oct 26 06:00:00 1919 UT = Sun Oct 26 01:00:00 1919 EST isdst=0 gmtoff=-18000
EST5EDT Mon Feb 9 06:59:59 1942 UT = Mon Feb 9 01:59:59 1942 EST isdst=0 gmtoff=-18000
EST5EDT Mon Feb 9 07:00:00 1942 UT = Mon Feb 9 03:00:00 1942 EWT isdst=1 gmtoff=-14400
EST5EDT Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 18:59:59 1945 EWT isdst=1 gmtoff=-14400
EST5EDT Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 19:00:00 1945 EPT isdst=1 gmtoff=-14400
EST5EDT Sun Sep 30 05:59:59 1945 UT = Sun Sep 30 01:59:59 1945 EPT isdst=1 gmtoff=-14400
EST5EDT Sun Sep 30 06:00:00 1945 UT = Sun Sep 30 01:00:00 1945 EST isdst=0 gmtoff=-18000
EST5EDT 9223372036854689407 = NULL
EST5EDT 9223372036854775807 = NULL
OK? There's dump number one. Now let's compare to dump number two:
unicorn:~$ zdump -v -c 1918,1950 America/New_York
America/New_York -9223372036854775808 = NULL
America/New_York -9223372036854689408 = NULL
America/New_York Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT isdst=1 gmtoff=-14400
America/New_York Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT isdst=1 gmtoff=-14400
America/New_York Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 30 06:59:59 1919 UT = Sun Mar 30 01:59:59 1919 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 30 07:00:00 1919 UT = Sun Mar 30 03:00:00 1919 EDT isdst=1 gmtoff=-14400
America/New_York Sun Oct 26 05:59:59 1919 UT = Sun Oct 26 01:59:59 1919 EDT isdst=1 gmtoff=-14400
America/New_York Sun Oct 26 06:00:00 1919 UT = Sun Oct 26 01:00:00 1919 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 28 06:59:59 1920 UT = Sun Mar 28 01:59:59 1920 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 28 07:00:00 1920 UT = Sun Mar 28 03:00:00 1920 EDT isdst=1 gmtoff=-14400
America/New_York Sun Oct 31 05:59:59 1920 UT = Sun Oct 31 01:59:59 1920 EDT isdst=1 gmtoff=-14400
America/New_York Sun Oct 31 06:00:00 1920 UT = Sun Oct 31 01:00:00 1920 EST isdst=0 gmtoff=-18000
[...]
I'm truncating this one because it's much longer. Apparently this one
shows every year, even if there are no DST rule changes that year. What
does this mean? Hell if I know. Let's pick a date that's in one of
these dumps but not the other, shall we?
unicorn:~$ TZ=America/New_York date -d '1920-03-28 +4 hours'
Sun Mar 28 05:00:00 EDT 1920
unicorn:~$ TZ=EST5EDT date -d '1920-03-28 +4 hours'
Sun Mar 28 04:00:00 EST 1920
There. There's a timestamp where you get a different result. I'm
sure there are more.
If being wrong about times in 1920 (and probably other years as well)
is not acceptable to you, then you should switch to America/New_York.
If the idea that you would ever CARE about the clock reading at various
times during the 1920s is laughable to you, then do whatever you want,
but please don't advocate that others follow your example.
Well since I am not going to set any of my systems to a time in 1920, then I believe I am save from the time machines.
On Wed, Dec 06, 2023 at 02:50:50PM -0500, Pocket wrote:
Well since I am not going to set any of my systems to a time in 1920, then I believe I am save from the time machines.It's not just about your system's current time. It's about timestamps
that you handle in any kind of software. If you process dates and times
from the past, e.g. in a database application, and intend to display
them to humans, then you'll want to use a historically accurate timezone.
Likely none for times present and future, unless Eric Adams should
pass a timezone bill. (In the 2010s, several U.S. states considered legislation to move from the Eastern Time Zone to Atlantic Standard
Time, allegedly.)
But I've already posted an example in this thread where these
timezones give different answers:
https://lists.debian.org/debian-user/2023/12/msg00329.html
Cheers,
David.
Because DST was not in force/usage except the metro NYC. Every where else didn't use/have it.
That makes EST5DST correct except for NYC and America/New_York completely incorrect except of course NYC.
On 12/6/23 19:12, Greg Wooledge wrote:
So, basically every reference I can find, and every reference I've *ever* found, other than Pocket's email, has said that America/New_York is
correct for me.
See my other post
On Wed, Dec 06, 2023 at 07:23:18PM -0500, Pocket wrote:
On 12/6/23 19:12, Greg Wooledge wrote:[citation needed]
So, basically every reference I can find, and every reference I've *ever* >>> found, other than Pocket's email, has said that America/New_York isSee my other post
correct for me.
On 12/6/23 19:26, Greg Wooledge wrote:
On Wed, Dec 06, 2023 at 07:23:18PM -0500, Pocket wrote:
On 12/6/23 19:12, Greg Wooledge wrote:
So, basically every reference I can find, and every reference I've *ever*
found, other than Pocket's email, has said that America/New_York is correct for me.
See my other post[citation needed]
See my other post
On Wed, Dec 06, 2023 at 07:37:32PM -0500, Pocket wrote:
On 12/6/23 19:26, Greg Wooledge wrote:If you mean<https://lists.debian.org/debian-user/2023/12/msg00376.html>
On Wed, Dec 06, 2023 at 07:23:18PM -0500, Pocket wrote:See my other post
On 12/6/23 19:12, Greg Wooledge wrote:[citation needed]
So, basically every reference I can find, and every reference I've *ever* >>>>> found, other than Pocket's email, has said that America/New_York isSee my other post
correct for me.
there are zero URLs in your text. "Someone named Pocket said so" is not a strong enough assertion for me to reject every other source citation
I've found.
On 12/6/23 15:28, David Wright wrote:
Likely none for times present and future, unless Eric Adams should
pass a timezone bill [...]
Which BTW this whole discussion about timezones is just water over the dam.
The system should be set to UTC, the "timezone" issue is really just a "human" issue as the UTC clock is always correct
On 12/6/23 15:28, David Wright wrote:
Likely none for times present and future, unless Eric Adams should
pass a timezone bill. (In the 2010s, several U.S. states considered legislation to move from the Eastern Time Zone to Atlantic Standard
Time, allegedly.)
But I've already posted an example in this thread where these
timezones give different answers:
https://lists.debian.org/debian-user/2023/12/msg00329.html
Which BTW this whole discussion about timezones is just water over the dam.
The system should be set to UTC, the "timezone" issue is really just a "human" issue as the UTC clock is always correct
the current America/New_York equiv is:
EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00
On Wed 06 Dec 2023 at 18:16:42 (-0500), Pocket wrote:
Which BTW this whole discussion about timezones is just water over the dam.
The system should be set to UTC, the "timezone" issue is really just a "human" issue as the UTC clock is always correct
While I'm glad we're not discussing whether or not the RTC is set to
UTC or TAI or local time, I do want my computers to display to /me/ the correct date and time corresponding to my location. And when I travel,
I expect my phone to switch its display automatically, using some
reasonably up-to-date tables.
On Wed, Dec 06, 2023 at 11:46:50PM -0600, David Wright wrote:
On Wed 06 Dec 2023 at 18:16:42 (-0500), Pocket wrote:I haven't had time to read and follow up on Pocket's list of references,
Which BTW this whole discussion about timezones is just water over the dam. >>>While I'm glad we're not discussing whether or not the RTC is set to
The system should be set to UTC, the "timezone" issue is really just a
"human" issue as the UTC clock is always correct
UTC or TAI or local time, I do want my computers to display to /me/ the
correct date and time corresponding to my location. And when I travel,
I expect my phone to switch its display automatically, using some
reasonably up-to-date tables.
but I'd like to respond to these points with a real anecdote.
One of our systems at work uses a database with a web front end, where
users input the starting and ending times of medical tests that have
been performed on a patient. When the tests are finished, and all the
data have been entered, billing charges are generated, and these charges depend on the length of the test.
You'd think that you can determine the length of the test by subtracting
the start time from the end time, right? Unfortunately, that fails
two times a year, if you don't do it exactly right. The naive approach
of simply looking at the time field ("test started at 01:45 and ended
at 03:15 the same day, so it must have lasted 90 minutes") is wrong.
You have to look at the entire date-plus-time as a single timestamp,
and interpret it within the correct time zone. That test might have been
90 minutes, or it might have been 30 minutes, or it might have been 150 minutes, depending on whether a DST transition happened in that interval,
and which way the clock moved.
I *literally* had to fix that bug (in March). This isn't hypothetical.
Of course, the system I'm dealing with only covers tests that have been performed recently, not tests from a century ago. So the historical interpretation of times under previous government DST rules *is*
hypothetical as far as this anecdote goes. But I hope some of you can appreciate it nonetheless.
You'd think that you can determine the length of the test by
subtracting the start time from the end time, right?
Greg writes:
You'd think that you can determine the length of the test byThat would have worked had the times been stored as UTC (better yet, TAI
subtracting the start time from the end time, right?
or Unix time since UTC can cause a similar problem). Databases should
never store local time.
On 12/7/23 09:22, John Hasler wrote:
Greg writes:
You'd think that you can determine the length of the test byThat would have worked had the times been stored as UTC (better yet, TAI
subtracting the start time from the end time, right?
or Unix time since UTC can cause a similar problem). Databases should never store local time.
Yes that is true.
I use UTC on all my systems as I have some windows machines, one win
xp dell laptop and two win 7 one laptop and one desktop.
- IANA TZ DB does not support timezones disappeared before 1970.
<https://data.iana.org/time-zones/theory.html#accuracy>
On Fri, Dec 08, 2023 at 09:38:43AM +0700, Max Nikulin wrote:Of minor interest to me, not once in the above link does it credit the
- IANA TZ DB does not support timezones disappeared before 1970.
<https://data.iana.org/time-zones/theory.html#accuracy>
Ohhh, *this* is the kind of reference I've been looking for.
So, we simply acknowledge that historical clock information prior to 1970
is just not feasibly discoverable. All of the time zone choices are
going to be flawed, for almost all of the people in the world. We just
pick from the ones that are known to be good enough.
.
Of minor interest to me, not once in the above link does it credit the K&R Manual for C, which has a method for determining leap years.
[...] a method for determining leap years. It was also
used in some astronomical programs for lunar and solar eclipses. This I
think was the reason that all unix times start at midnight 1/1/1970. In the FWIW dept this time formula is pretty accurate back to the middle of 4713
BC.
Also, the idea that a calculation of *anything* in our current Gregorian calendar system would extend back to a BC date is ludicrous [...]
In the FWIW dept this time formula is pretty accurate back to the
middle of 4713 BC.
Even the *Julian* calendar used in ancient Rome wouldn't have been in
use in 4713 BC. Any calendar would have been locally defined, if one
existed at all.
Hi Greg,
bool isleapyear (int year) {
if (year % 400 == 0) return true;
if (year % 100 == 0) return false;
if (year % 4 == 0) return true;
return false;
}
Except, I think it should be in reverse order because now 2000 first gets a true, then a false but then a true again and after that EVERYTHING gets a false ;-)
So, in pseudo code
bool isleapyear (int year) {
return false;
if (year % 4 == 0) return true;
if (year % 100 == 0) return false;
if (year % 400 == 0) return true;
}
On Fri, Dec 08, 2023 at 09:38:43AM +0700, Max Nikulin wrote:
- IANA TZ DB does not support timezones disappeared before 1970.
<https://data.iana.org/time-zones/theory.html#accuracy>
Ohhh, *this* is the kind of reference I've been looking for.
So, we simply acknowledge that historical clock information prior to 1970
is just not feasibly discoverable. All of the time zone choices are
going to be flawed, for almost all of the people in the world. We just
pick from the ones that are known to be good enough.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 31:19:02 |
| Calls: | 6,669 |
| Calls today: | 1 |
| Files: | 12,216 |
| Messages: | 5,338,150 |