3

I have Centos server, in which I don't want to jump back the time to one hour during time change. instead I want to slow down the system clock few hour before the time change so that when the time jumps back, my server should sync with latest time after time change

  • 2
    If you keep the server's RTC on UTC it won't change for DST at all, only the displayed time will change. You can avoid watching that by sleeping through it. :) With the server on UTC, you also don't have to worry about all the DST-change related issues in file timestamps, and you can stay sync'd with real time. If you start serving web pages and use SSL you'll want to stay accurate with your time anyway. – Gypsy Spellweaver Jan 30 '17 at 5:47
  • What you're wanting to do is not possible. You're better off using GMT/UTC time because the time will not ever change on the server. – Sokel Jan 30 '17 at 6:20
  • The problem is, I have to be on PST time zone. And I thought about moving to any other time zone. But that's not an option for me :( . – Mat55 Jan 30 '17 at 22:44
3

As said in the comments, switching on DST won't change your machine time at all, only the timezone. Therefore you don't need to mess with the server clock (and you're advised not to).

On a side note, there's a project that does something similar to what you want. Google uses it to "smear" the extra second over a longer time whenever the IERS enforces a leap second. Basically, during a whole day, Google server clocks run a bit slower so that when the leap second is applied at midnight the servers experience no time jump. Again, I add this just FYI -- this is not a solution for your case.

  • 1
    @Mat55 The system clock does not jump. It counts the number of seconds since 1970-01-01T00:00:00Z. Only the conversion of the system clock to a timezone with DST jumps, and that happens due to the definition of DST. If you have a broken application that forgets that 01:00 PST ≠ 01:00 PDT, pause it during the time change — fiddling with the system time won't help you. – Gilles Jan 30 '17 at 22:54
  • @dr01 - I agree with your comment, Time change will only change the timezone, and that happens sharp at 2:00AM. What I am looking for is, I want to stop NTP sync and then try to slow down the clock so that it shouldn't appear as time jump. At 2:00AM I will again restart the NTP service. – Mat55 Apr 11 '17 at 8:22
2

I think there's a timezone confusion here.

The expected way to keep time on a Unix/Linux system is to have the BIOS clock and the kernel system clock running on UTC. You then have one (or more) time zones for your users. The time zone conversion ensures that the underlying UTC clock is displayed in the user's local time.

Let's try to give an example:

# UTC date/time as known by the system clock
date -u
Tue 31 Jan 14:06:23 UTC 2017

# Local time in the UK
TZ=Europe/London date
Tue 31 Jan 14:06:25 GMT 2017

# Local time in France
TZ=Europe/Paris date
Tue 31 Jan 15:06:27 CET 2017

# Local time in west coast USA
TZ=US/Pacific date
Tue 31 Jan 06:06:30 PST 2017

Here's another one:

# UTC absolute reference
TZ=UTC ls -l whos_pointing.txt
-rw-r--r-- 1 roaima roaima 143 Jan 31 14:08 whos_pointing.txt

# Local time in the UK
TZ=Europe/London ls -l whos_pointing.txt
-rw-r--r-- 1 roaima roaima 143 Jan 31 14:08 whos_pointing.txt

# Local time in France
TZ=Europe/Paris ls -l whos_pointing.txt
-rw-r--r-- 1 roaima roaima 143 Jan 31 15:08 whos_pointing.txt

# Local time in west coast USA
TZ=US/Pacific ls -l whos_pointing.txt
-rw-r--r-- 1 roaima roaima 143 Jan 31 06:08 whos_pointing.txt

The file is the same file, but its date/time is displayed differently depending on where the system thinks I am at any point.

# Back in the USA
export TZ=US/Pacific
ls -l whos_pointing.txt
-rw-r--r-- 1 roaima roaima 143 Jan 31 06:08 whos_pointing.txt
touch whos_pointing.txt
ls -l whos_pointing.txt
-rw-r--r-- 1 roaima roaima 143 Jan 31 06:16 whos_pointing.txt

# Jump across to the UK. Notice the file's timestamp has updated here too
export TZ=Europe/London
ls -l whos_pointing.txt
-rw-r--r-- 1 roaima roaima 143 Jan 31 14:16 whos_pointing.txt

It's not difficult to set up a system-wide default timezone, nor is it difficult for particular users to override that with the TZ environment variable. I have a server in California where the default timezone is US/Pacific but my own login account contains export TZ=Europe/London.

The timezone conversion libraries automatically handle the jump between summer and winter time in the timezones where they are applied. The system clock does not jump, but the hourly (or half-hourly) offset is modified at the appropriate instant. Database systems use the system's absolute time internally, so they are unaffected by apparent jumps forwards or backwards in the users' displayed time. NTP also works with system absolute time, which is how it can handle servers in different timezones around the world (it doesn't need to worry!).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.