setting the time

[snork]

Here's my problem. I created a livecd (on usb stick) that boots to a custom written program that I've written. The program relies on the HW clock being set to UTC time. i.e. when you issue the 'date' command, it shows UTC date/time. I have it set the OS to use NTP servers to get the time.

When the computer is hard wired (Ethernet cable), the computer boots, connects to an NTP server, sets the time and everything works. However, if the computer is using Wi-Fi, the program boots and the time/date is set to local time, even after the computer connects to the Wi-Fi modem, and connects to the internet. It doesn't update the clock (either hardware or software clock) to UTC time, even though when I go into the setup program, it shows that the time zone is UTC.

So, why doesn't it get updated? How long does it take for it to update, assuming that it actually WILL update the clocks? What's the proper way to handle or correct this situation? How can I make sure that the clocks are set to UTC, before letting my program run? Can I check to see if it can actually connect to a NTP server and get the time before running my program?

I always thought (and have researched this) that the hardware clock is always set to UTC time, but MS Windows (and Linux) users can change this to local time, although they shouldn't.

Any help in how to solve my program would be greatly appreciated.

[Just18]

Maybe some of these would be useful ......

Code:

/usr/sbin/ntp-wait
/usr/sbin/ntpd
/usr/sbin/ntpdate
/usr/sbin/ntpdc
/usr/sbin/ntpq
/usr/sbin/ntpstat
/usr/sbin/ntptime

This is what I get from ntpstat

Code:

ntpstat
unsynchronised
  time server re-starting
   polling server every 64 s

Later I got

Code:

ntpstat
synchronised to NTP server (91.208.177.20) at stratum 11
   time correct to within 449 ms
   polling server every 64 s

It seemed to take in excess of 5 mins to sync in the first place .....

[Bald Brick]

Here's my problem. I created a livecd (on usb stick) that boots to a custom written program that I've written. The program relies on the HW clock being set to UTC time. i.e. when you issue the 'date' command, it shows UTC date/time. I have it set the OS to use NTP servers to get the time.

The date command does not read the hardware clock. Plain date shows your system time as your local time, date -u  shows your system time as UTC time, but in neither case does it show the time your hardware clock is set to.

If you set your local time zone to UTC, then date and date -u will of course show the same time. Whether that really is UTC depends on how you set your clocks....

When the computer is hard wired (Ethernet cable), the computer boots, connects to an NTP server, sets the time and everything works. However, if the computer is using Wi-Fi, the program boots and the time/date is set to local time, even after the computer connects to the Wi-Fi modem, and connects to the internet. It doesn't update the clock (either hardware or software clock) to UTC time, even though when I go into the setup program, it shows that the time zone is UTC.

With the information given I can't answer that. Is the NTP daemon running in both cases?

So, why doesn't it get updated? How long does it take for it to update, assuming that it actually WILL update the clocks? What's the proper way to handle or correct this situation? How can I make sure that the clocks are set to UTC, before letting my program run? Can I check to see if it can actually connect to a NTP server and get the time before running my program?

The command

Code:

ntpq -p

should show you whether you are connected or not. An asterisk in front of a server URL tells you that you are synchronized to that server, a plus sign that a server is good enough to use.

Note that the system clock is synchronized to the hardware clock at boot and the hardware clock to the system clock at shutdown. (With the line

Code:

[ -x /sbin/hwclock ] && action "Syncing hardware clock to system time" /sbin/hwclock --systohc

in /etc/rc.d/init.d/halt.)

In between, the hardware clock is neither read nor written to unless you do it manually or have changed the default settings. (It's quite possible to let the system adjust the hardware clock every time the NTP daemon has adjusted the system time. Usually this wouldn't make sense though.)

I always thought (and have researched this) that the hardware clock is always set to UTC time, but MS Windows (and Linux) users can change this to local time, although they shouldn't.

Correct, although most forum members have their hardware clocks set to local time without any ill effects. (Some people get away with anything....)

Any help in how to solve my program would be greatly appreciated.

[djohnston]

When the computer is hard wired (Ethernet cable), the computer boots, connects to an NTP server, sets the time and everything works. However, if the computer is using Wi-Fi, the program boots and the time/date is set to local time, even after the computer connects to the Wi-Fi modem, and connects to the internet. It doesn't update the clock (either hardware or software clock) to UTC time, even though when I go into the setup program, it shows that the time zone is UTC.

With the information given I can't answer that. Is the NTP daemon running in both cases?

Because it works with an ethernet connection, I'm thinking the SPEEDBOOT=auto setting in etc/sysconfig/speedboot is at work here. When using wireless, the network isn't up yet when the NTP daemon tries to connect. That's been my experience.

[dougmack]

Clarification, please:

BaldBrick says "Note that the system clock is synchronized to the hardware clock at boot and the hardware clock to the system cloick at shutdown. (With the line Code:

[ -x /sbin/hwclock ] && action "Syncing hardware clock to system time" /sbin/hwclock --systohc

in /etc/rc.d/init.d/halt.)"

I have my hardware clock set to UTC and my system clock to local (Eastern) time.  If I put in that line, will it force the hardware
clock to local time?  I wouldn't want that.  I thought that the system, when told to sync with NTP, set the hardware clock. No?

[Bald Brick]

Clarification, please:

BaldBrick says "Note that the system clock is synchronized to the hardware clock at boot and the hardware clock to the system cloick at shutdown. (With the line Code:

[ -x /sbin/hwclock ] && action "Syncing hardware clock to system time" /sbin/hwclock --systohc

in /etc/rc.d/init.d/halt.)"

I have my hardware clock set to UTC and my system clock to local (Eastern) time.  If I put in that line, will it force the hardware
clock to local time?  I wouldn't want that.

No, it won't. It would be logical if it would (particularly as one could interpret the man page for hwclock that way), but if UTC is specified in /etc/adjtime (and together with your local time zone in /etc/sysconfig/clock) it won't. And actually the line is probably already present in your /etc/rc.d/init.d/halt. I'd be very surprised if it isn't.

I thought that the system, when told to sync with NTP, set the hardware clock. No?

No. The NTP daemon sets the system clock.

[kjpetrie]

The system clock is in the kernel. The hardware clock is normally only used to store the time between boots when the system clock is not running, as Bald Brick explained. It can store it in local time or UTC, and it doesn't matter which as long as the OS knows which one to use and all OSes which are booted on the same hardware agree about that.

Whatever the clocks are set to, NTP will set it correctly for the specified time zone. If the problem relates to NTP trying to sync before the network is ready the time should become correct after about half an hour. However, there must be something seriously wrong with the clock set up if the time comes up wrong. Either you are dual-booting two OSes with different time zone settings, or you have one set to expect the hardware clock in UTC and the other set to expect it in local time.

[Just18]

The system clock is in the kernel. The hardware clock is normally only used to store the time between boots when the system clock is not running, as Bald Brick explained. It can store it in local time or UTC, and it doesn't matter which as long as the OS knows which one to use and all OSes which are booted on the same hardware agree about that.

Whatever the clocks are set to, NTP will set it correctly for the specified time zone. If the problem relates to NTP trying to sync before the network is ready the time should become correct after about half an hour. However, there must be something seriously wrong with the clock set up if the time comes up wrong. Either you are dual-booting two OSes with different time zone settings, or you have one set to expect the hardware clock in UTC and the other set to expect it in local time.

None of which is controllable when using a Live session on unknown hardware owned by someone else.

[kjpetrie]

Well spotted, Just18!

If the program needs the time to be correct it must not be run until the network has been connected and NTP has had time to set the clock.

Also, that line which sets the hardware clock on shutdown must be removed from halt or you'll be altering people's time settings and they won't like that.