Re: ntpsec as server questions

On 05/12/2023 01:41, Greg Wooledge wrote: unicorn:~$ LC_TIME=en_US.utf8 printf '%(%c)T\n' Mon 04 Dec 2023 01:34:42 PM EST Sadly, you're restricted to the choices offered by your installed locales. If you can't find an installed locale which has an acceptable LC_TIME format, then you can try to

Re: Local time in databases (Re: ntpsec as server questions)

On 08/12/2023 11:38, to...@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

Re: ntpsec as server questions

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

ntpsec as server questions

I had a total crash and among the things missing after the psu was replaced, was apparently all my tbird message tags, as I had been tagging this whole thread so I could look it up again after the dust settled. But now I have no tags. ISTR someone gave me a journalctl line that picked out all

Re: ntpsec as server questions

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. > > > > Ohhh, *this* is the kind of reference

Re: ntpsec as server questions

On Fri, Dec 08, 2023 at 04:12:54PM +, 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

RE: ntpsec as server questions

Hi Greg, > 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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

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 > 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,

Re: Local time in databases (Re: ntpsec as server questions)

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

Re: Local time in databases (Re: ntpsec as server questions)

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

Re: ntpsec as server questions

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. Ohhh, *this* is the kind of reference I've been looking for. So, we

Re: Local time in databases (Re: ntpsec as server questions)

On Thu, Dec 7, 2023, 8:11 PM 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

Re: ntpsec as server questions

On Fri, Dec 08, 2023 at 09:38:43AM +0700, Max Nikulin wrote: > - IANA TZ DB does not support timezones disappeared before 1970. > Ohhh, *this* is the kind of reference I've been looking for. So, we simply acknowledge that historical clock

Re: ntpsec as server questions

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

Re: Local time in databases (Re: ntpsec as server questions)

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

Re: Local time in databases (Re: ntpsec as server questions)

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

Re: ntpsec as server questions

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

Local time in databases (Re: ntpsec as server questions)

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

Re: ntpsec as server questions

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).

Re: ntpsec as server questions

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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On Wed 06 Dec 2023 at 20:44:29 (-0500), Pocket wrote: > On 12/6/23 19:46, Greg Wooledge wrote: > > On Wed, Dec 06, 2023 at 07:37:32PM -0500, Pocket wrote: > > > 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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On 12/6/23 19:46, Greg Wooledge wrote: On Wed, Dec 06, 2023 at 07:37:32PM -0500, Pocket wrote: 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

Re: ntpsec as server questions

On Wed, Dec 06, 2023 at 07:37:32PM -0500, Pocket wrote: > > 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* >

Re: ntpsec as server questions

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.

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On 12/6/23 19:12, Greg Wooledge wrote: On Wed, Dec 06, 2023 at 06:11:16PM -0500, 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

Re: ntpsec as server questions

On Wed, Dec 06, 2023 at 06:11:16PM -0500, 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. (EST5EDT not EST5DST.) Now

Re: ntpsec as server questions

On 12/6/23 18:28, Greg Wooledge wrote: 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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On 12/6/23 15:41, David Wright wrote: On Wed 06 Dec 2023 at 13:27:40 (-0500), Greg Wooledge 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.

Re: ntpsec as server questions

 Sent from my iPad > On Dec 6, 2023, at 1:28 PM, Greg Wooledge 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

Re: ntpsec as server questions

the current America/New_York equiv is: EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00 -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6

Re: ntpsec as server questions

On Wed 06 Dec 2023 at 13:27:40 (-0500), Greg Wooledge 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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On 12/6/23 12:55, Greg Wooledge wrote: On Wed, Dec 06, 2023 at 05:40:00PM -, Curt wrote: 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

Re: ntpsec as server questions

On Wed, Dec 06, 2023 at 05:40:00PM -, Curt wrote: > 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. > >

Re: ntpsec as server questions

On 2023-12-06, Max Nikulin wrote: > > 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

Re: ntpsec as server questions

On 12/6/23 12:24, Greg Wooledge wrote: On Wed, Dec 06, 2023 at 12:06:04PM -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 I take that as chaos

Re: ntpsec as server questions

On Wed, Dec 06, 2023 at 12:06:04PM -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 > > I take that as chaos reins supreme and one zone is no

Re: ntpsec as server questions

On 12/6/23 11:42, Max Nikulin wrote: 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

Re: ntpsec as server questions

On Wed, Dec 06, 2023 at 11:28:40AM -0500, Pocket wrote: > 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 unicorn:/usr/share/zoneinfo$ ls -l EST5EDT -rw-r--r-- 1 root root 2310 May

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On 2023-12-06, Greg Wooledge wrote: > > Honestly, I don't see the appeal of using legacy time zone names. Is > it just for the sake of contrariness? > No lack of contrariness around here. There exists such a thing as putting too fine a point on a thing, a notion which appears to escape some

Re: ntpsec as server questions

On 12/6/23 11:18, Greg Wooledge wrote: On Wed, Dec 06, 2023 at 10:44:42AM -0500, Pocket wrote: Well POSIX has worked for me since the days of Xenix and System V. Well, most of the goofy time zone changes were all *before* that. But there's at least one that happened more recently

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On 12/6/23 10:07, Max Nikulin wrote: 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: dpkg-reconfigure tzdata That does not work. Cannot set EST5EDT.  you have to do that manually. Do

Re: ntpsec as server questions

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: 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

Re: ntpsec as server questions

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: On 05/12/2023 05:14, Pocket wrote: For gene [...] dpkg-reconfigure tzdata That does not work. Cannot set EST5EDT. 

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On Tue 05 Dec 2023 at 23:37:31 (+0700), Max Nikulin wrote: > On 05/12/2023 05:14, Pocket wrote: > > For gene.. > [...] > > zone=EST5EDT > > zoneinfo=/usr/share/zoneinfo > > localtime=/etc/localtime > > timezone=/etc/timezone > >

Re: ntpsec as server questions

On 12/5/23 12:21, gene heskett wrote: On 12/5/23 11:38, Max Nikulin wrote: On 05/12/2023 05:14, Pocket wrote: For gene.. [...] zone=EST5EDT zoneinfo=/usr/share/zoneinfo localtime=/etc/localtime timezone=/etc/timezone

Re: ntpsec as server questions

On 12/5/23 11:38, Max Nikulin wrote: 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

Re: ntpsec as server questions

On 12/5/23 11:37, Max Nikulin wrote: 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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On Mon 04 Dec 2023 at 16:24:11 (-0500), gene heskett wrote: > 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 > > >

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On 5/12/23 04:52, Darac Marjal wrote: Most people know what timezone they're currently in, but the more likely know what their nearest city is. Cities rarely change, but timezones do. Take the example of Triana in Paul Eggert's original email. The city never moved, but the timezone it was

Re: ntpsec as server questions

On 12/4/23 15:28, 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.

Re: ntpsec as server questions

On Mon 04 Dec 2023 at 15:36:32 (-0500), Greg Wooledge wrote: > 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

Re: ntpsec as server questions

On 12/4/23 14:17, Greg Wooledge wrote: On Mon, Dec 04, 2023 at 02:11:51PM -0500, gene heskett wrote: 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:

Re: ntpsec as server questions

On 12/4/23 11:39, John Hasler wrote: 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

Re: ntpsec as server questions

On 12/4/23 11:34, Greg Wooledge wrote: 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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On 04/12/2023 20:36, Greg Wooledge wrote: On Mon, Dec 04, 2023 at 03:19:33PM -0500, gene heskett wrote: 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

Re: ntpsec as server questions

On Mon, Dec 04, 2023 at 03:19:33PM -0500, gene heskett wrote: > 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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On Mon, Dec 04, 2023 at 02:11:51PM -0500, gene heskett wrote: > 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

Re: ntpsec as server questions

On 12/4/23 07:10, Greg Wooledge wrote: On Mon, Dec 04, 2023 at 06:32:38AM -0500, gene heskett wrote: On 12/4/23 05:55, Pocket wrote: ntpq -p I don't have that on the printer, it is running chrony. A quick Google search for "chrony equivalent of ntpq" gives me

Re: ntpsec as server questions

On Tue, Dec 05, 2023 at 12:01:35AM +0700, Max Nikulin wrote: > 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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

gene heskett writes: > 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? There's no offset. 15:00 UTC *is* 03:00 PM UTC ^^

Re: ntpsec as server questions

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

Re: ntpsec as server questions

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 > > === > ^*

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On 12/4/23 07:10, Greg Wooledge wrote: On Mon, Dec 04, 2023 at 06:32:38AM -0500, gene heskett wrote: On 12/4/23 05:55, Pocket wrote: ntpq -p I don't have that on the printer, it is running chrony. A quick Google search for "chrony equivalent of ntpq" gives me

Re: ntpsec as server questions

On 12/4/23 07:17, Greg Wooledge wrote: On Mon, Dec 04, 2023 at 05:55:25AM -0500, Pocket wrote: 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

Re: ntpsec as server questions

On Mon, Dec 04, 2023 at 05:55:25AM -0500, Pocket wrote: > 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

Re: ntpsec as server questions

On Mon, Dec 04, 2023 at 06:32:38AM -0500, gene heskett wrote: > On 12/4/23 05:55, Pocket wrote: > > ntpq -p > I don't have that on the printer, it is running chrony. A quick Google search for "chrony equivalent of ntpq" gives me

Re: ntpsec as server questions

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. > >

Re: ntpsec as server questions

On 12/4/23 05:55, Pocket wrote: ntpq -p I don't have that on the printer, it is running chrony. 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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On 12/4/23 03:58, gene heskett wrote: 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

Re: ntpsec as server questions

jeremy ardley 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

Re: ntpsec as server questions

On 12/4/23 00:09, to...@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

Re: ntpsec as server questions

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

Re: ntpsec as server questions

On Mon, Dec 4, 2023 at 1:23 AM Charles Curley wrote: > > On Mon, 4 Dec 2023 00:20:45 -0500 > Jeffrey Walton 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

Re: ntpsec as server questions

On Mon, 4 Dec 2023 00:20:45 -0500 Jeffrey Walton 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

Re: ntpsec as server questions

On Mon, Dec 4, 2023 at 12:09 AM 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 > >

Re: ntpsec as server questions

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

  1   2   >