Score:1

Mexico NTP (no more time changes since 2023) and my NTP server

sa flag
SOV

I have a NTP server (Ubuntu) that actually have a Time Zone of America/Mexico_City, until 2022 we have had 2 time changes a year, most Americans spring forward (turn clocks ahead and lose an hour) on the second Sunday in March (at 2:00 A.M.) and fall back (turn clocks back and gain an hour) on the first Sunday in November (at 2:00 A.M.), this time change was done automatically by NTP server but in october 2022 in Mexico was established by president that from 2023 there will no be time changes any more from now, so as this was done automatically, how can I configure NTP server in order to NOT to have any time change from now? do I have to configure something additional? or will be reflected automatically?

I have configured ubuntu ntp server by default in ntp.conf: pool 0.ubuntu.pool.ntp.org iburst pool 1.ubuntu.pool.ntp.org iburst pool 2.ubuntu.pool.ntp.org iburst pool 3.ubuntu.pool.ntp.org iburst

ru flag
This isn't configurable at the NTP server level, this is entirely dependent on your system's time zone libraries. Most if not all NTP servers speak UTC and give you a UTC timezone, and your system adapts by offsetting based on your tz libraries on your system. You need to update your systems that USE the NTP server on how to handle timezone changes. NTP *itself* has no mechanisms for awareness.
ru flag
Case in point I have a Stratum 1 (GPS integrated) NTP server on my network. It simply serves the time data from the GPS timepulse signals, which are UTC. How my downstream systems that reach for that data handle that data is dependent on the `tzdata` package on those downstream systems (or Windows' time zone libraries, because I have two Windows servers that sync to that Stratum 1 NTP server)
ru flag
@guiverc not really, we can completely untag `lubuntu` and the question stands on its own. OP is asking about **NTP server** which has nothing to do with timezone offset handling and is not even *aware* of such things, so this is completely answerable
Score:2
ru flag

I think there is a fundamental misunderstanding here of how NTP actually works.

The actual NTP protocol and how NTP servers work are both time-zone agnostic. That is, the NTP servers - all of them - speak only UTC. It's the system that queries the NTP servers that handles the timezone offset and such.

Here's the example case - my laptop.

Here's some info for this case: My computer only has Ubuntu 22.04 installed on it, and Ubuntu installs by default assume the RTC (Real Time Clock) in the computer / system / BIOS is set to UTC. As such, the system itself is configured with timesyncd here to sync with Ubuntu's timeservers (NTP pool) and my local Stratum 1 NTP server (basically, an NTP server that is connected to time sync via GPS timepulse syncing; this server's local timezone is the same as mine, America/New_York, but that's only for the system locale, RTC and such are using UTC because that's how Ubuntu defaults to).

What my system does is it queries the NTP server for the current time and says what my current time is (in UTC), and is returned the current time AND offset in UTC from my current RTC clock.

My system (or in this case, timesyncd) will then take this offset and compare it against the system RTC time and adjust the system RTC based on the offset detected from the NTP query.

It is therefore not possible to set an NTP server if it's compliant with NTP spec to respond based off of timezone rules - those are controlled by the end point system and its locales, and the NTP server and how it behaves are completely oblivious to timezone offsets - in Ubuntu the timezone data for daylight savings time, etc. are all stored in tzdata and other system utilities, so you really need to be updating your endpoint machines on how to handle timezone offsetting and DST autoconfig - that's not an NTP server side function, that's a client-side function.

(Note that this is why I can query a time server in Japan from the United States and get my local timezone displayed still locally on my system, or querying a US server from Europe and get the proper system time - NTP itself doesn't care about the timezone offset it only speaks UTC. And NTP servers in general are fed from the stratum layout of servers - Stratum 0 aka general worldwide time are powered by atomic clocks; Stratum 1 are pulling from GPS, etc. sources which are synced from Stratum 0 data sources; Stratum 2 servers feed from Stratum 1 servers; Stratum 3 feed from stratum 2, etc.)

Score:1
cn flag

For all those not able to upgrade tzdata, there's an easy way to update this data by updating the IANA DB

wget https://data.iana.org/time-zones/releases/tzdata2023c.tar.gz
tar xvzf tzdata2023c.tar.gz
sudo zic africa
sudo zic antarctica
sudo zic asia
sudo zic australasia
sudo zic europe
sudo zic northamerica
sudo zic southamerica
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.