Regarding API to query the system clock

Not sure there is anyway to get the system clock, but there is ExRegisterCallback/ExCreateCallback that will allow you to know when the windows system clock is changed. With a little work you can get correction factor.

Of course the bigger question is what are you really trying to do? There are a lot of time calls in the kernel, understanding better the goal can help.

Another option is to use the Kernel Winsock functions to query an NNTP time server to get the internet time, but that will require you to have an active internet connection as well as a list of NNTP servers (since they come and go) … but as @DonBurns said, what is the problem you are attempting to solve?

I don’t want to rely on the windows system clock which can be changed by external entity.

What makes you think there is some other clock? Your computer does not know the absolute time. You can get relative time since boot, or you can get the system clock’s approximation of wall clock time, which can be reset. There is no other option.

If your application needs absolute time, then you need NTP or GPS.

And now I know that @craig_howard is an old-timer – NNTP was the old Usenet newsgroup protocol. That was still a better way to exchange technical information than web forums.

((smile)) Yep, older than dirt but still younger than stone … point is, use an Internet time provider for an absolute timebase independent of the local computer …

At least I didn’t suggest to gopher for more info, or check the IRC channels! :smiley:

Create a user mode program that uses any of the reliable time services to provide your driver with the ‘correct’ time.

1 Like

I am trying to build a WORM compliance clock at kernel level.

Hmm … I would look into using the “winsock kernel” API’s (there are several good starting point libraries on GitHub) to query the internet time services directly, similar to how this program does it [http://www.thinkman.com/dimension4/] except in kernel mode to ensure security …

WORM compliance clock

Are you talking about the financial regulations that require certain records to be unalterable? It’s not clear to me how a kernel clock helps that, but in any case, surely you need your whole system to have reliable time, not just your driver. That’s exactly what NTP is for. No kernel work is necessary.

Hmmm … I think what the OP is looking for is a timebase that lives in kernel mode, immune from usermode tampering that he can use to adjust specific file timestamps with … specifically to prevent something from usermode adjusting the time (like an NTP service, or the user fiddling with control panel)

If that’s true, OP, then what you’re looking at is a file system filter driver (which there are several samples of) to make the file timestamp adjustments to files as they are modified as well as a Winsock Kernel connection to (several) NTP servers to get the correct time. You should test carefully to see what the OS is going to do if it thinks the time is 0500 Jan 15th 2025 but you adjust the filetime of “GottaGetThisRight.doc” to the NTP time of 0600 July 13th 2021 and the reverse …

I admit that you may be right, but honestly, a computer that is being used for that kind of work needs to be trustworthy, more than just one kernel driver.

2 Likes

@Tim_Roberts said:

WORM compliance clock

Are you talking about the financial regulations that require certain records to be unalterable? It’s not clear to me how a kernel clock helps that

I have seen a case where something similar was the case, yes. I.e. if a user began creating an inspection report at HH:MM local time, then used local time must grow monotonically from that point on. I.e. have some assurance that no one will later modify local time (be it OS action to sync up time to nntp time or user tampering with) i.e. windows time service nor daylight savings time setting shall not touch local time - otherwise there is large liability issue.
That problem was solved differently from Windows 10 software.

daylight savings does not adjust the system clock. If the user selected time zone of any particular logged in user happens to have daylight savings, the times that they see will be altered by an appropriate offset

General relativity tells us that time itself is not absolute, but within this context it is much more subjective than using a sundial.

Most modern hardware has several sources of time information available locally. some are more accurate than others, but the sources of time derived from local hardware resources can’t really be influenced by code than runs on the machine - but they don’t really survive a reboot

a discussion of salient points can be found here

https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps

and the whole topic in MSDN is informative, but many of the issues listed are legacy ones that modern hardware is not subject to. The core quantization problems are not.

The system clock values are derived from a combination of these hardware based sources plus external sources like NTP or radio (typically GPS). It is meant to fluctuate from the local hardware because the local hardware is not particularly accurate

now comes the problem of the reliability of the system clock itself and the ways in which it could be tampered with. unless you have a hardware device that can keep reliable independent time, KM versus UM doesn’t make much difference except that in KM you can theoretically tamper with the clock in arbitrary ways

This is just a short summary of some of the problems of accurate time. there is much more detail if you want to do this in any sort of reliable way

@MBond2 said:
daylight savings does not adjust the system clock.
This is just a short summary of some of the problems of accurate time. there is much more detail if you want to do this in any sort of reliable way

Don’t need those details, thank you had that in the past.
Yes daylight savings does not change Windows system clock. Please note I described real case when a report was based on local clock, which may change when user enables/disables daylight savings time setting.

unless you have a hardware device that can keep reliable independent time,
In this particular case customer preferred to have independent (from Windows) source of time for their reports, yes in hardware.
Independent clock need not be precise to milliseconds, but all it has to do is be under exclusive control of customer software, i.e. no one else has access to it.

I don’t know what you mean by ‘local clock’ but everything that ordinary users see is based on their configured settings and the system clock

To provide a time source that is independent of windows, build a PCIe board and put a clock on it

I’ve had good luck with the TimeMachines TM1000A. It listens to GPS satellites and provides an NTP server on your local network, plus it has a separate line with a millisecond pulse if you need to sync more precisely.

@MBond2 said:
I don’t know what you mean by ‘local clock’
The report generation was a legacy software initially using Windows API GetLocalTime() functions all over the place. Customer then discovered that if a user changes time zone (intentionally or otheriwise) then time stamps in report become inconsistent, i.e. local time from GetLocalTime() jumps 1 hr. Report with such time stamps becomes invalid (by the rules back then).
Another issue they did not like was Windows time service adjusting system time (and consequently local time) when synchronizing with cellular network when became available.
Yet another issue was that cellular operator was broadcasting incorrect local time after daylight savings time change event for some period.

It was then.

To provide a time source that is independent of windows, build a PCIe board and put a clock on it
As I recall an external USB gismo was used which contained both a security key for report encryption and RTC clock with battery which was only accessible to report software. When starting a new report the operator was responsible to ensure that the time they use was best known correct local time for location where they were at (first read local time as Windows reports it, then take necessary action to correct to reality). After that moment any time stamps in report were based on guaranteed monotonic time from that separate clock.

@Tim_Roberts GPS is a good thing for such purpose, but has limitations. And FYI on one day I was presented a true photograph where side by side a commercial upper scale Garmin GPS and a commercial cell phone were showing local time different by 1 hr. Correct time zone was selected on both. Whom would you trust

TimeMachines TM1000A

What a cute little device. I’m tempted to get one just for fun.

ETA: But it doesn’t keep time (“hold over”) when it loses GPS, which would not work for me. You apparently need the TM2000B for that… a lot more expensive. Sorry… I’m a time nut.

Peter

The TimeMachines TM2000B is cool. However, I cannot tell may be Tim knows - this machine only broadcasts UTC time to local network. On the other hand it has GPS and knows location, therefore it could also know time zone for that location and therefore tell local time at location - does it? Would be helpful.

It does know your lat and long, and can deliver that over a UDP port, but the time it delivers is UTC. Really, that’s appropriate; an NTP server might be quite a distance away from its client, so time at the device is probably not so useful.

1 Like

Good to know. For the case I refer to the local time on the device is most important (as local time goes into report), not UTC time. If using this time machine human operator is responsible for setting time zone correctly on their notebook from location data to get local time at location be correct.