Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #264173 > unrolled thread
| Started by | gene heskett <gheskett@shentel.net> |
|---|---|
| First post | 2023-12-04 01:50 +0100 |
| Last post | 2023-12-04 11:00 +0100 |
| Articles | 20 on this page of 99 — 17 participants |
Back to article view | Back to linux.debian.user
ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 01:50 +0100
Re: ntpsec as server questions jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-04 02:00 +0100
Re: ntpsec as server questions jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-04 02:10 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 10:00 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-04 12:00 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 12:40 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 13:20 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 17:00 +0100
Re: ntpsec as server questions Dan Purgert <dan@djph.net> - 2023-12-04 17:40 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:30 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-05 04:00 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 17:40 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-04 18:10 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 19:50 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-16 11:40 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:30 +0100
Re: ntpsec as server questions John Hasler <john@sugarbit.com> - 2023-12-04 17:40 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:40 +0100
Re: ntpsec as server questions Tom Furie <tom@furie.org.uk> - 2023-12-04 17:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 20:20 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:40 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 20:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 13:20 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-04 14:00 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 21:30 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 21:40 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-04 22:50 +0100
Re: ntpsec as server questions jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-05 00:50 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 21:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-04 23:20 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-05 17:40 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-05 18:10 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-06 13:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 14:10 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-06 16:10 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 16:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 17:20 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 17:30 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 17:50 +0100
Re: ntpsec as server questions Curt <curty@free.fr> - 2023-12-06 17:50 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-05 18:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-05 18:30 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-06 06:30 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-06 17:50 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 18:10 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 18:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 18:40 +0100
Re: ntpsec as server questions Curt <curty@free.fr> - 2023-12-06 18:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 19:00 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 19:10 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 19:30 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-06 21:50 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 00:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 01:20 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 01:30 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 01:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 01:40 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 01:50 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 02:50 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 06:50 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-08 03:40 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 04:10 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-08 05:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 13:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 18:00 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-09 12:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 13:40 +0100
Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-08 14:20 +0100
Re: ntpsec as server questions "Thomas Schmitt" <scdbackup@gmx.net> - 2023-12-08 14:40 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-08 18:10 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-06 21:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 00:20 +0100
Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-07 06:40 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 06:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 13:20 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 14:10 +0100
Re: ntpsec as server questions John Hasler <john@sugarbit.com> - 2023-12-07 15:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 15:40 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 17:00 +0100
Local time in databases (Re: ntpsec as server questions) Max Nikulin <manikulin@gmail.com> - 2023-12-07 16:40 +0100
Re: Local time in databases (Re: ntpsec as server questions) <tomas@tuxteam.de> - 2023-12-07 17:10 +0100
Re: Local time in databases (Re: ntpsec as server questions) Max Nikulin <manikulin@gmail.com> - 2023-12-08 03:20 +0100
Re: Local time in databases (Re: ntpsec as server questions) Nicholas Geovanis <nickgeovanis@gmail.com> - 2023-12-08 05:20 +0100
Re: Local time in databases (Re: ntpsec as server questions) <tomas@tuxteam.de> - 2023-12-08 05:40 +0100
Re: Local time in databases (Re: ntpsec as server questions) Max Nikulin <manikulin@gmail.com> - 2023-12-12 18:10 +0100
Re: Local time in databases David Wright <deblis@lionunicorn.co.uk> - 2023-12-17 06:20 +0100
Re: Local time in databases (Re: ntpsec as server questions) <tomas@tuxteam.de> - 2023-12-08 05:40 +0100
Re: ntpsec as server questions James Cloos <cloos@jhcloos.com> - 2023-12-06 22:30 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 06:50 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-05 04:00 +0100
Re: ntpsec as server questions Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2023-12-04 11:10 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 12:30 +0100
Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-04 12:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 02:00 +0100
Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-04 06:10 +0100
Re: ntpsec as server questions Jeffrey Walton <noloader@gmail.com> - 2023-12-04 06:30 +0100
Re: ntpsec as server questions Charles Curley <charlescurley@charlescurley.com> - 2023-12-04 07:30 +0100
Re: ntpsec as server questions Jeffrey Walton <noloader@gmail.com> - 2023-12-04 08:10 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 11:00 +0100
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-08 03:40 +0100 |
| Message-ID | <HIyWt-c4wO-7@gated-at.bofh.it> |
| In reply to | #264362 |
On 07/12/2023 06:11, Pocket wrote: > > 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. > > Which is why I prefer to use EST5DST It may be a valid reason, however - You stated that you do not care concerning historical timestamps. - It is still unclear for me for what territory EST5EDT is more correct than America/New_York or another similar timezone. My expectation is that America/New_York is accurate at least for New York and America/Detroit is accurate for Detroit. - EST5EDT in Debian is extension in respect to POSIX. - America/New_York and EST2EDT are both provided by the same tzdata package, so quality of America/New_York is not worse. - IANA TZ DB does not support timezones disappeared before 1970. <https://data.iana.org/time-zones/theory.html#accuracy> - After 1970 these timezones have no discrepancy. > BTW there isn't any timezone called America/New_York, it is or course > the Eastern Standard Time Zone. > > America/New_your should actually be called America/Eastern. The POSIX > EST5DST is closer to being correct. For me America/New_York is just an identifier. Perhaps you do not like this city for some reason, but for me it has no negative context. Decisions related to identifiers are clarified in <https://data.iana.org/time-zones/theory.html#naming> After all ls -l /usr/share/zoneinfo/US/Eastern lrwxrwxrwx 1 root root 19 May 29 2023 /usr/share/zoneinfo/US/Eastern -> ../America/New_York For most of users I still recommend to stick to names like America/New_York. I would not neglect IANA TZ DB just because it has usual disclaimer. Despite POSIX is a standard, I see efforts to keep TZ DB accurate. That is why reputation of IANA, Arthur David Olson, and Paul Eggert has more value for me.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-08 04:10 +0100 |
| Message-ID | <HIzpv-c4Vm-1@gated-at.bofh.it> |
| In reply to | #264404 |
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.
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-08 05:20 +0100 |
| Message-ID | <HIAvf-c5CX-3@gated-at.bofh.it> |
| In reply to | #264405 |
On 12/7/23 22:08, Greg Wooledge wrote: > 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. > > . 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. 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. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-08 13:20 +0100 |
| Message-ID | <HIHZL-caet-1@gated-at.bofh.it> |
| In reply to | #264407 |
On Thu, Dec 07, 2023 at 11:19:19PM -0500, gene heskett wrote:
> 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.
The what now? Leap years are defined by the Gregorian Calendar, as
declared in the 16th century, long before K&R.
https://en.wikipedia.org/wiki/Gregorian_calendar
The rule for leap years is:
Every year that is exactly divisible by four is a leap year, except
for years that are exactly divisible by 100, but these centurial years
are leap years if they are exactly divisible by 400. For example, the
years 1700, 1800, and 1900 are not leap years, but the year 2000 is.
— United States Naval Observatory[2]
I don't have my copy of K&R close to hand, but my preferred implementation
for a function that decides leap years is (pseudo-code):
bool isleapyear (int year) {
if (year % 400 == 0) return true;
if (year % 100 == 0) return false;
if (year % 4 == 0) return true;
return false;
}
Why would you expect a time zone database to acknowledge one
implementation of a simple Gregorian leap year function?
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-08 18:00 +0100 |
| Message-ID | <HIMmJ-ccEE-17@gated-at.bofh.it> |
| In reply to | #264415 |
On Fri, Dec 08, 2023 at 04:12:54PM +0000, Bonno Bloksma wrote:
> 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 ;-)
No, because "return" is immediate. It's not "set the return value to this,
and then that'll be the thing the function returns when you reach the end".
It's "return this value RIGHT NOW and don't go any farther".
> 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;
> }
Your way should be:
bool isleapyear (int year) {
bool ret = false;
if (year % 4 == 0) ret = true;
if (year % 100 == 0) ret = false;
if (year % 400 == 0) ret = true;
return ret;
}
Your way does three modulus operations every time, no matter what. Mine
will do fewer than 3 if it gets lucky (input is a multiple of 100).
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-09 12:20 +0100 |
| Message-ID | <HJ3xf-cne1-5@gated-at.bofh.it> |
| In reply to | #264415 |
On 08/12/2023 23:12, Bonno Bloksma wrote:
> So, in pseudo code
> bool isleapyear (int year) {
> return false;
I've heard such a calendar was in use in ancient Egypt.
https://en.wikipedia.org/wiki/Sothic_cycle
Its disadvantage was that crop reaping and tax paying dates were slowly
becoming out of sync. However every 1461 years it was returning to
originally established order.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-08 13:40 +0100 |
| Message-ID | <HIIj7-cakl-7@gated-at.bofh.it> |
| In reply to | #264407 |
On Thu, Dec 07, 2023 at 11:19:19PM -0500, gene heskett wrote: > [...] 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. You're not actually talking about leap years, are you? Are you maybe talking about *Easter*? Or something involving the spring equinox? Also, the idea that a calculation of *anything* in our current Gregorian calendar system would extend back to a BC date is ludicrous, as the Gregorian calendar was not in use at that time. It wasn't invented until thousands of years later. 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.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-08 14:20 +0100 |
| Message-ID | <HIIVQ-caMs-13@gated-at.bofh.it> |
| In reply to | #264416 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Dec 08, 2023 at 07:32:25AM -0500, Greg Wooledge wrote: [...] > Also, the idea that a calculation of *anything* in our current Gregorian > calendar system would extend back to a BC date is ludicrous [...] The high-class version of this swear word would be "proleptic". But yeah, I agree with you :-) For all the mess involved, and how the calendar change moved through the so-called civilised world, or not, see [1]. Revolts and all (because folks tended to believe they had been stolen days of their lives). Now look at a birth date recorded back then in some small-village parish by a priest "under spirits" and guess what the real Unix time was back then ;^) Cheers [1] https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_calendar -- t
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2023-12-08 14:40 +0100 |
| Message-ID | <HIJfb-caSb-1@gated-at.bofh.it> |
| In reply to | #264416 |
Hi, gene heskett wrote: > > In the FWIW dept this time formula is pretty accurate back to the > > middle of 4713 BC. Greg Wooledge wrote: > 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. What Gene describes is the Julian Date, an astronomical time counting. I first met it in HP BASIC but it is also used by database systems. 0.000000 is 1st Januar 4713 BC 12:00 UTC (year -4712 because the is no year 0 in BC/AD counting). It must not be confused with the Julian Calendar, which invented the the 4-year leap year rule. This worked until pope Gregor saw the need for a finer adjustment to the day fractions of the astronomical year. This yielded the rules about 100 and 400 years. Afaik, they all suffer from being day-oriented which makes trouble because the astronomical days get longer over time and thus cause leap seconds. For long term accuracy in the range of seconds one needs to work with time countings close to International Atomic Time (TAI) which is nearly perfect but becomes only available up to a month too late. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-08 18:10 +0100 |
| Message-ID | <HIMwp-ccX5-3@gated-at.bofh.it> |
| In reply to | #264405 |
On Thu 07 Dec 2023 at 22:07:44 (-0500), Greg Wooledge wrote: > 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. Where it's felt important enough, or is accessible enough, people are prepared, it seems, to do the necessary work. Britain appears to lead the world in that respect. It probably helps to be a small, civilized country. :) https://www.polyomino.org.uk/british-time/ On the subject of leap seconds, I think there's a point that's missed on this Wiki page: https://en.wikipedia.org/wiki/Greenwich_Time_Signal where it says: "Until 1972, the pips were of equal length and confusion arose as to which was the final pip, hence the last pip is now of extended length." My recollection is of listening to the first "leap pip" on Radio4, which was the first time the final pip had been made longer. (There had been discussions about leap seconds on Radio4 in the lead up to the event.) Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-06 21:30 +0100 |
| Message-ID | <HI6GR-bNlE-3@gated-at.bofh.it> |
| In reply to | #264348 |
On Wed 06 Dec 2023 at 12:06:04 (-0500), Pocket wrote: > 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 Time zones are a civil and legal matter, so non-authoritative would mean that the tz database would not be evidence in a court of law. > I take that as chaos reins supreme and one zone is no better or worst > that the other(s) > > IE there is no "standard" We all depend on there being a standard to live our daily lives. It's only when you start compiling all the standards that have been and will be used that it starts to resemble "chaos", particularly in some parts of the world. (The US appears to have been one of those areas in the not so distant past.) Fixes and enhancements means that as changes are reported or discovered, the database is corrected. There's a constant trickle of future changes being made by governments. People also discover historical inaccuracies from literature, like old legal documents and newspaper archives. I respect their research. On Wed 06 Dec 2023 at 13:02:45 (-0500), Pocket wrote: > TZ=POSIX;date > Wed Dec 6 18:00:38 POSIX 2023 You've got a choice of writing something like posix/America/New_York or posixrules, though IDK where the last name came from. (I don't think it can be New Jersey on this occasion.) > 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? 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.
[toc] | [prev] | [next] | [standalone]
| From | Pocket <pocket@columbus.rr.com> |
|---|---|
| Date | 2023-12-07 00:20 +0100 |
| Message-ID | <HI9ln-bPbg-3@gated-at.bofh.it> |
| In reply to | #264352 |
[Multipart message — attachments visible in raw view] — view raw
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 > > Cheers, > David. > 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 -- It's not easy to be me
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-07 06:40 +0100 |
| Message-ID | <HIfh7-bSKt-1@gated-at.bofh.it> |
| In reply to | #264361 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Dec 06, 2023 at 06:16:42PM -0500, Pocket wrote: > > 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. But still interesting and very much on-topic, because it invites us all to question our incomplete and naive knowledge. > The system should be set to UTC, the "timezone" issue is really just a > "human" issue as the UTC clock is always correct If we are picking nits, the system is set to UTX (aka "Unix time"), which is, in itself, difficult to grasp and very near (but not equal) to UTC [1]. The closer you look the messier it gets. UTC, TAI, UT0, UT1... oh, my [2]. Cheers [1] https://unix.stackexchange.com/questions/283164/unix-seconds-tai-si-seconds-leap-seconds-and-real-world-code [2] http://www.stjarnhimlen.se/comp/time.html -- t
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-07 06:50 +0100 |
| Message-ID | <HIfqN-bSNR-11@gated-at.bofh.it> |
| In reply to | #264361 |
On Wed 06 Dec 2023 at 18:16:42 (-0500), Pocket wrote: > 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 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. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-07 13:20 +0100 |
| Message-ID | <HIlwe-bWzV-1@gated-at.bofh.it> |
| In reply to | #264378 |
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:
> > 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.
I haven't had time to read and follow up on Pocket's list of references,
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.
[toc] | [prev] | [next] | [standalone]
| From | Pocket <pocket@columbus.rr.com> |
|---|---|
| Date | 2023-12-07 14:10 +0100 |
| Message-ID | <HImiB-bX5K-25@gated-at.bofh.it> |
| In reply to | #264385 |
On 12/7/23 07:16, Greg Wooledge wrote:
> 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:
>>> 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.
> I haven't had time to read and follow up on Pocket's list of references,
> 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.
I worked with time keeping systems for a major player in the business
back in 1995.
That feature of the government reared its ugly head back then as well.
People get more irate when they are not payed properly then they are
from being over billed,
trust me been there done that.
>
> 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.
>
--
It's not easy to be me
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <john@sugarbit.com> |
|---|---|
| Date | 2023-12-07 15:30 +0100 |
| Message-ID | <HIny1-bXKB-1@gated-at.bofh.it> |
| In reply to | #264385 |
Greg writes: > You'd think that you can determine the length of the test by > subtracting the start time from the end time, right? That would have worked had the times been stored as UTC (better yet, TAI or Unix time since UTC can cause a similar problem). Databases should never store local time. -- John Hasler john@sugarbit.com Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | Pocket <pocket@columbus.rr.com> |
|---|---|
| Date | 2023-12-07 15:40 +0100 |
| Message-ID | <HInHH-bXO3-3@gated-at.bofh.it> |
| In reply to | #264387 |
On 12/7/23 09:22, John Hasler wrote: > Greg writes: >> You'd think that you can determine the length of the test by >> subtracting the start time from the end time, right? > That would have worked had the times been stored as UTC (better yet, TAI > 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. The dell seems to be too old to use bookworm and the others are used for apps that only run on windows (3d cad engineering) I just purchased a new laptop yesterday (the price was too good to pass up) so I guess I will find out the trials and tribulations of installing bookworm on a new machine with secure boot and the new boot systems. I have only have experience with BIOS boot loaders. Maybe there will be another thread for that ;) -- It's not easy to be me
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-07 17:00 +0100 |
| Message-ID | <HIoX7-bYy9-9@gated-at.bofh.it> |
| In reply to | #264388 |
On Thu 07 Dec 2023 at 09:37:29 (-0500), Pocket wrote: > On 12/7/23 09:22, John Hasler wrote: > > Greg writes: > > > You'd think that you can determine the length of the test by > > > subtracting the start time from the end time, right? > > That would have worked had the times been stored as UTC (better yet, TAI > > 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. That must be very confusing if you mean that, for example, the bash prompt after you'd just sent that post said: hostname!pocket 14:38:29 ~$ Even if databases store UTC, they have to have front ends on local time for data entry and reporting, unless you're going to have no human involvement. And those original dates and times need to be preserved or recreatable for auditing against any contemporary records that are in local time. There may be several "local times" in use in large organisations. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-07 16:40 +0100 |
| Subject | Local time in databases (Re: ntpsec as server questions) |
| Message-ID | <HIoDL-bYrk-3@gated-at.bofh.it> |
| In reply to | #264387 |
On 07/12/2023 21:22, John Hasler wrote: > Databases should never store local time. I am anticipating a new branch of hot discussion. There are exceptions when storing UTC instead of local time leads to undesired consequences. Planned (future) events may be bound namely to local time. So if timezone offset rules are changed due to new administrative regulations then UTC timestamp becomes invalid. I do not mean regular spring and fall time transitions related to DST. It may be decided to cancel or to introduce DST, to shift dates when it is effective, to change time offset for some territory. 10:00am local time remains 10:00am despite before a new bill it is 15:00 UTC and it will be 14:00 UTC after. This is a case for various calendar applications. Historical documents specify local time. Time zone database may contain incorrect data. Fixing TZ DB should not change local time for the stored event. Additional data may be required when local time is stored: time zone identifier, disambiguation rule in the case of backward time transition close to the event time, location for the case that existing time zone will be split. Despite calculation may be performed using UTC timestamps, local time is definitive in these cases.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web