0

We have an app deployed to information kiosks across a number of sites, where employees of our client can log in and sign-on/off their shifts and view timesheets etc. Approaching every daylight savings changeover, we've had problems with some kiosks displaying shits in the future beyond the DST changeover as an hour off. Thing is, often by the time the incident has worked its way through the system onto my desk its magically fixed itself. With some careful tracing and 6 months of patience, I no longer believe our code is the problem so I'm looking at other possibilites.

The kiosk computers are set up to sync with a time server. When an sync occurs, is daylight savings information also pushed onto the client - that is, if the clients had incorrect DST info, would it be corrected?

the registry key HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/W32Time/TimeProviders/NtpClient/SpecialPollInterval is set to 604800, which means the computer syncs every 7 days - is that correct? How can I check when the last sync was?

Can I check when the last update to the DST info on the NTP server was performed?

What other possibilities might cause this behaviour that I should look into?

Improve this question

1 Answer 1

Reset to default
0

Question #1: Can I check when the last update to the DST info on the NTP server was performed?

You can not check the last time ntp updated DST. ntp uses UTC so there is no DST involved. This can not be the fault of an ntp sync.

Question #2: What other possibilities might cause this behaviour that I should look into?

If you are in the US it might be related to the 2005 change in DST.^1 However I am not sure how this would be the culprit. At the very least it would require that one component of your system is using outdated DST definitions.

Improve this answer

You must log in to answer this question.