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 | 19 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 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-07 17:10 +0100 |
| Subject | Re: Local time in databases (Re: ntpsec as server questions) |
| Message-ID | <HIp6N-bYQF-5@gated-at.bofh.it> |
| In reply to | #264389 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Dec 07, 2023 at 10:29:29PM +0700, Max Nikulin wrote: > 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. Heh. There was one huge thread in Emacs user about a year ago (don't ask me in which time zone). You are right. Sometimes local time is the right thing. Sometimes it's the wrong thing. Context matters and so on. After having a long and fruitless discussion with a customer (they insisted in having local time in a log file, which is almost always the wrong thing) I came to the conclusion that in such situations it's best to give them what they want -- but store time zone *and* time offset with it. > Planned (future) events may be bound namely to local time. So if timezone > offset rules are changed [...] Yep, that's one of those. Even on a planned change -- regular planned events are local time: show up at work at 10 o'clock means local time. [...] The intersection of technology and "human stuff" is often messy. Look closely at Unicode to have yet another bunch of fun :-) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-08 03:20 +0100 |
| Subject | Re: Local time in databases (Re: ntpsec as server questions) |
| Message-ID | <HIyD7-c4qN-1@gated-at.bofh.it> |
| In reply to | #264393 |
On 07/12/2023 23:08, tomas wrote: > On Thu, Dec 07, 2023 at 10:29:29PM +0700, Max Nikulin wrote: >> On 07/12/2023 21:22, John Hasler wrote: >>> Databases should never store local time. >> >> There are exceptions when storing UTC instead of local time leads to >> undesired consequences. > > Heh. There was one huge thread in Emacs user about a year ago (don't > ask me in which time zone). Perhaps you mean emacs-ormode. Then an important difference arises. Timestamp are stored not in a database, but in a plain text file and must be human readable, moreover some users prefer to type timestamps directly without dedicated commands. Leaving aside future timestamps that may need local time, significant fraction of timestamps may be reliably represented in UTC. I still have no clue why some people were strongly against local time with explicit time offset "2023-12-07 17:08:50 +0100". From my point of view such format may be unambiguously mapped to UTC "2023-12-07T16:08:50Z" and more convenient for users residing in Europe/Berlin. There were participants insisting on either forcing UTC or using IANA identifiers "2023-12-07 17:08:50 Europe/Berlin". The latter format has issues close to backward DST time shifts and should be augmented with disambiguation hints. > After having a long and fruitless discussion with a customer (they > insisted in having local time in a log file, which is almost always > the wrong thing) I came to the conclusion that in such situations > it's best to give them what they want -- but store time zone *and* > time offset with it. Local time is widely used in logs. The question is if the client can accept ambiguity LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 00:30' '+%F %T' 2023-10-29 02:30:00 LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 01:30' '+%F %T' 2023-10-29 02:30:00 That are LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 00:30' '+%F %T %z %Z' 2023-10-29 02:30:00 +0200 CEST LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 01:30' '+%F %T %z %Z' 2023-10-29 02:30:00 +0100 CET Another case to consider it integration with 3rd party log analyzing tools and time formats that they can parse. As I said above I see nothing wrong in local time with explicit time offset. Mail has been using it for decades: > Date: Thu, 7 Dec 2023 17:08:50 +0100
[toc] | [prev] | [next] | [standalone]
| From | Nicholas Geovanis <nickgeovanis@gmail.com> |
|---|---|
| Date | 2023-12-08 05:20 +0100 |
| Subject | Re: Local time in databases (Re: ntpsec as server questions) |
| Message-ID | <HIAvf-c5CX-1@gated-at.bofh.it> |
| In reply to | #264403 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Dec 7, 2023, 8:11 PM Max Nikulin <manikulin@gmail.com> wrote: > On 07/12/2023 23:08, tomas wrote: > > On Thu, Dec 07, 2023 at 10:29:29PM +0700, Max Nikulin wrote: > >> On 07/12/2023 21:22, John Hasler wrote: > >>> Databases should never store local time. > >> > >> There are exceptions when storing UTC instead of local time leads to > >> undesired consequences. > > > > Heh. There was one huge thread in Emacs user about a year ago (don't > > ask me in which time zone). > > Perhaps you mean emacs-ormode. > .... > Leaving aside future timestamps that may need local time, significant > fraction of timestamps may be reliably represented in UTC. > .... > As I said above I see nothing wrong in local time with explicit time > offset. Mail has been using it for decades: > > Date: Thu, 7 Dec 2023 17:08:50 +0100 > All of these considerations are what brought Oracle to create a proprietary "datetime" datatype and use it to store all "real" dates/times. If you need a different format for display purposes or a human readable column, you can extract it and do that. But the internal representation will be driven by other needs. YMMV :-)
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-08 05:40 +0100 |
| Subject | Re: Local time in databases (Re: ntpsec as server questions) |
| Message-ID | <HIAOB-c5IA-1@gated-at.bofh.it> |
| In reply to | #264406 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Dec 07, 2023 at 10:18:44PM -0600, Nicholas Geovanis wrote: [...] > All of these considerations are what brought Oracle to create a proprietary > "datetime" datatype and use it to store all "real" dates/times. If you need > a different format for display purposes or a human readable column, you can > extract it and do that. But the internal representation will be driven by > other needs. > YMMV :-) If anyone is looking for inspiration, I think what PostgreSQL does is one of the best and most complete implementations I've seen. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-12 18:10 +0100 |
| Subject | Re: Local time in databases (Re: ntpsec as server questions) |
| Message-ID | <HKeqB-d6Z3-5@gated-at.bofh.it> |
| In reply to | #264408 |
On 08/12/2023 11:38, tomas@tuxteam.de wrote: > On Thu, Dec 07, 2023 at 10:18:44PM -0600, Nicholas Geovanis wrote: > >> All of these considerations are what brought Oracle to create a proprietary >> "datetime" datatype and use it to store all "real" dates/times. If you need >> a different format for display purposes or a human readable column, you can >> extract it and do that. But the internal representation will be driven by >> other needs. > > If anyone is looking for inspiration, I think what PostgreSQL does is one of > the best and most complete implementations I've seen. I know nothing concerning the datetime type in Oracle. Postgres stores timestamps as a numbers. Its power is reliable conversion to client time zone (or between time zones). "timestamp with time zone" is actually duration since epoch (UTC) and conversion to a time zone on select. However storing local time might be tricky. A week may have 2 Fridays with the same date. zdump -v America/Juneau America/Juneau Sat Oct 19 00:31:12 1867 UT = Sat Oct 19 15:33:31 1867 LMT isdst=0 gmtoff=54139 America/Juneau Sat Oct 19 00:31:13 1867 UT = Fri Oct 18 15:33:32 1867 LMT isdst=0 gmtoff=-32261 Some territories crossed the international date line.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-17 06:20 +0100 |
| Subject | Re: Local time in databases |
| Message-ID | <HLRJg-e7KE-3@gated-at.bofh.it> |
| In reply to | #264666 |
On Wed 13 Dec 2023 at 00:03:57 (+0700), Max Nikulin wrote: > On 08/12/2023 11:38, tomas@tuxteam.de wrote: > > On Thu, Dec 07, 2023 at 10:18:44PM -0600, Nicholas Geovanis wrote: > > > > > All of these considerations are what brought Oracle to create a proprietary > > > "datetime" datatype and use it to store all "real" dates/times. If you need > > > a different format for display purposes or a human readable column, you can > > > extract it and do that. But the internal representation will be driven by > > > other needs. > > > > If anyone is looking for inspiration, I think what PostgreSQL does is one of > > the best and most complete implementations I've seen. > > I know nothing concerning the datetime type in Oracle. > > Postgres stores timestamps as a numbers. Its power is reliable > conversion to client time zone (or between time zones). "timestamp > with time zone" is actually duration since epoch (UTC) and conversion > to a time zone on select. > > However storing local time might be tricky. A week may have 2 Fridays > with the same date. > > zdump -v America/Juneau > > America/Juneau Sat Oct 19 00:31:12 1867 UT > = Sat Oct 19 15:33:31 1867 LMT isdst=0 gmtoff=54139 > America/Juneau Sat Oct 19 00:31:13 1867 UT > = Fri Oct 18 15:33:32 1867 LMT isdst=0 gmtoff=-32261 > > Some territories crossed the international date line. Let's hope that the trappers were aware of the ambiguity, and for those two days used offsets instead, for recording their kills at the local courthouse. At least they didn't have to reset their pocket watches. :) Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-08 05:40 +0100 |
| Subject | Re: Local time in databases (Re: ntpsec as server questions) |
| Message-ID | <HIAOB-c5IA-5@gated-at.bofh.it> |
| In reply to | #264403 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Dec 08, 2023 at 09:11:12AM +0700, Max Nikulin wrote: > On 07/12/2023 23:08, tomas wrote: > > On Thu, Dec 07, 2023 at 10:29:29PM +0700, Max Nikulin wrote: > > > On 07/12/2023 21:22, John Hasler wrote: > > > > Databases should never store local time. > > > > > > There are exceptions when storing UTC instead of local time leads to > > > undesired consequences. > > > > Heh. There was one huge thread in Emacs user about a year ago (don't > > ask me in which time zone). > > Perhaps you mean emacs-ormode. Right, that was it. I envy your memory :-) > Then an important difference arises. > Timestamp are stored not in a database, but in a plain text file and must be > human readable, moreover some users prefer to type timestamps directly > without dedicated commands. The difference is there, but basically, it's minor. > Leaving aside future timestamps that may need local time, significant > fraction of timestamps may be reliably represented in UTC. I still have no > clue why some people were strongly against local time with explicit time > offset "2023-12-07 17:08:50 +0100". From my point of view such format may be > unambiguously mapped to UTC "2023-12-07T16:08:50Z" and more convenient for > users residing in Europe/Berlin. There were participants insisting on either > forcing UTC or using IANA identifiers "2023-12-07 17:08:50 Europe/Berlin". > The latter format has issues close to backward DST time shifts and should be > augmented with disambiguation hints. 100% agreement. Perhaps *both* is best: the time zone (to keep "intention") and the offset (to keep "actual time"). If I could go backwards in time (heh ;-), that's what I would have talked that customer into. [...] > Local time is widely used in logs. The question is if the client can accept > ambiguity This was an industrial application logging measurements from machines all over the place (and to different log files), so if a shed went up in flames, you'd be comparing different logs to each other to try to find out what went wrong. So no, IMO not in that case. It took me days of talking :-) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | James Cloos <cloos@jhcloos.com> |
|---|---|
| Date | 2023-12-06 22:30 +0100 |
| Message-ID | <HI7CV-bO6x-7@gated-at.bofh.it> |
| In reply to | #264347 |
the current America/New_York equiv is: EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00 -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-07 06:50 +0100 |
| Message-ID | <HIfqN-bSNR-5@gated-at.bofh.it> |
| In reply to | #264354 |
On Wed 06 Dec 2023 at 16:21:37 (-0500), James Cloos wrote: > the current America/New_York equiv is: > > EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00 That's as may be, but this discussion revolves around: "The M format is sufficient to describe many common daylight-savings transition laws. But note that none of these variants can deal with daylight-savings law changes, so in practice the historical data stored for named time zones (in the IANA time zone database) is necessary to interpret past time stamps correctly." (from some random POSIX Time Zone Specifications) Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-05 04:00 +0100 |
| Message-ID | <HHtPc-bfgU-7@gated-at.bofh.it> |
| In reply to | #264247 |
On Mon 04 Dec 2023 at 15:28:03 (-0500), gene heskett wrote:
> 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.
If by fixed, you mean it should have changed the time zone of the
machine, you obviously didn't read the man page:
Note that tzselect will not actually change the timezone for you.
Use 'dpkg-reconfigure tzdata' to achieve this.
nor the output from the program:
$ tzselect
Please identify a location so that time zone rules can be set correctly.
Please select a continent, ocean, "coord", or "TZ".
1) Africa
2) Americas
3) Antarctica
4) Asia
5) Atlantic Ocean
6) Australia
7) Europe
8) Indian Ocean
9) Pacific Ocean
10) coord - I want to use geographical coordinates.
11) TZ - I want to specify the timezone using the Posix TZ format.
#? 11
Please enter the desired value of the TZ environment variable.
For example, AEST-10 is abbreviated AEST and is 10 hours
ahead (east) of Greenwich, with no daylight saving time.
EST5EDT
The following information has been given:
TZ='EST5EDT'
Therefore TZ='EST5EDT' will be used.
Selected time is now: Mon Dec 4 21:42:03 EST 2023.
Universal Time is now: Tue Dec 5 02:42:03 UTC 2023.
Is the above information OK?
1) Yes
2) No
#? 1
You can make this change permanent for yourself by appending the line
↑↑↑↑↑↑↑↑↑↑↑↑
TZ='EST5EDT'; export TZ
to the file '.profile' in your home directory; then log out and log in again.
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
Here is that TZ value again, this time on standard output so that you
can use the /usr/bin/tzselect command in shell scripts:
EST5EDT
$
(I've assumed you want the old value rather than America/New_York.)
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> |
|---|---|
| Date | 2023-12-04 11:10 +0100 |
| Message-ID | <HHe3M-b2X4-11@gated-at.bofh.it> |
| In reply to | #264176 |
jeremy ardley <jeremy.ardley@gmail.com> writes: > timedatectl status I think you mean timedatectl timesync-status since that lists the NTP server among other things. Interestingly, looks like my Debian router uses my ISP's NTP server which it likely knows through DHCP whereas my little Ubuntu-running Raspberry Pi uses ntp.ubuntu.com.
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-04 12:30 +0100 |
| Message-ID | <HHfjb-b3LU-1@gated-at.bofh.it> |
| In reply to | #264199 |
On 12/4/23 05:03, Anssi Saari wrote: > timedatectl timesync-status root@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? 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 | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-04 12:50 +0100 |
| Message-ID | <HHfCx-b3SZ-3@gated-at.bofh.it> |
| In reply to | #264203 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Dec 04, 2023 at 06:29:24AM -0500, gene heskett wrote: > On 12/4/23 05:03, Anssi Saari wrote: > > timedatectl timesync-status > root@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? Please, don't mix up local time (a device to show to you, done somewhere in libc) with kernel time (as traded between NTP and friends). That way lies madness. Kernel time is *always* number of seconds since some Epoch (typically 1970-01-01). No EST or whatever nonsense in there. And this is the terms in which NTPs trade (OK, they have fractions of sec in there, but that's it). Nothing else. Unix boxes aren't DOS, haven't ever been. Actually you should know that. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-04 02:00 +0100 |
| Message-ID | <HH5tv-aTUu-7@gated-at.bofh.it> |
| In reply to | #264173 |
On Sun, Dec 03, 2023 at 07:42:42PM -0500, gene heskett wrote: > 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; > ---------- I have never once seen a host use NTP servers which were suggested by a DHCP server. I can't speak for others. I would simply ignore that section, but if you feel like you want your hosts to be told which NTP servers to use via DHCP, then you can try it.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-04 06:10 +0100 |
| Message-ID | <HH9nr-aXeu-1@gated-at.bofh.it> |
| In reply to | #264173 |
[Multipart message — attachments visible in raw view] — view raw
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 -- t
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2023-12-04 06:30 +0100 |
| Message-ID | <HH9GN-aXDP-1@gated-at.bofh.it> |
| In reply to | #264187 |
On Mon, Dec 4, 2023 at 12:09 AM <tomas@tuxteam.de> wrote: > > 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). 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. Jeff
[toc] | [prev] | [next] | [standalone]
| From | Charles Curley <charlescurley@charlescurley.com> |
|---|---|
| Date | 2023-12-04 07:30 +0100 |
| Message-ID | <HHaCR-aYRd-1@gated-at.bofh.it> |
| In reply to | #264188 |
On Mon, 4 Dec 2023 00:20:45 -0500
Jeffrey Walton <noloader@gmail.com> wrote:
> 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>.
Well, I don't know about the RFC, but the ISC DHCP server gets along
find with host names. From my /etc/dhcp/dhcpd.conf:
option ntp-servers ntp.localdomain, ntp1.localdomain; # issola, aliased; chaffee, aliased.
I think the server looks the addresses up and transmits the addresses.
My clients see IP addresses, anyway.
>
> 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.
Well, that's silly. One of the nice things about using host names is
that you can move the service from one machine to another (as I just
did) and all you have to do is change the alias in your zone file.
I'm not going to look to see if a more recent RFC amends that.
--
Does anybody read signatures any more?
https://charlescurley.com
https://charlescurley.com/blog/
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2023-12-04 08:10 +0100 |
| Message-ID | <HHbfz-aZJV-1@gated-at.bofh.it> |
| In reply to | #264190 |
On Mon, Dec 4, 2023 at 1:23 AM Charles Curley <charlescurley@charlescurley.com> wrote: > > On Mon, 4 Dec 2023 00:20:45 -0500 > Jeffrey Walton <noloader@gmail.com> wrote: > > > 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>. > > Well, I don't know about the RFC, but the ISC DHCP server gets along > find with host names. From my /etc/dhcp/dhcpd.conf: > > option ntp-servers ntp.localdomain, ntp1.localdomain; # issola, aliased; chaffee, aliased. > > I think the server looks the addresses up and transmits the addresses. > My clients see IP addresses, anyway. > > > 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. > > Well, that's silly. One of the nice things about using host names is > that you can move the service from one machine to another (as I just > did) and all you have to do is change the alias in your zone file. > > I'm not going to look to see if a more recent RFC amends that. Well, I don't disagree with you: <https://forum.netgate.com/topic/184196/kea-dhcp-dont-resolve-a-ntp-br>. It makes sense that a hostname is resolved since it could reveal a pool of NTP servers. And then the server could send the IP addresses associated with the pool. But what do I know... Jeff
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-04 11:00 +0100 |
| Message-ID | <HHdU5-b2Cw-5@gated-at.bofh.it> |
| In reply to | #264187 |
On 12/4/23 00:09, tomas@tuxteam.de wrote: > 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). > The naked ipv4 address works, I've not added all machines to the printers hosts file, yet... > Cheers 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] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | linux.debian.user
csiph-web