Regarding API to query the system clock

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.

IMO it’s never a good idea to use local time to synchronize time across devices.

Imagine your device receives the time once per minute and then checks if its local time is correct.

At the beginning or end of DST, the next time information may be sent immediately before the DST status changes, so the client(s) may get the changed local time up to 1 minute delayed.

Even worse, if the client (like Windows, Linux, …) distinguishes between UTC and local time, this may cause a step in the underlying UTC system time, and another step back shortly thereafter.

Those UTC time steps won’t be visible at the first glance, but may really mess up other applications, e.g. database apps.

This is why time synchronization is usually made based on UTC (e.g. NTP) or TAI (e.g. PTP), and the client does the conversion from UTC to local time according to his preferences.

A good way to distribute local time would be to distribute the time zone rules which the client should use for a local time conversion, so the clients could be updated remotely but avoid the potential problems you get when distributing local time.

The tzdist protocol could be used to do that, but as far as I know it has not yet been implemented for this purpose.

For more details, please see also
https://kb.meinbergglobal.com/kb/time_sync/tzdist

1 Like

@Martin_Burnicki said:
IMO it’s never a good idea to use local time to synchronize time across devices.

This was a purpose built legacy device overloaded by legal regulations.
There was no time synchronization between devices at location. The valid report from a stand alone device was the sole purpose.

The task was simple - when creating a report on a notebook computer every entry must be time stamped. All that was needed is simple “what is correct local time now where I am at” when there is no radio reception. The solution wasn’t simple back then.
This becomes long story away from NTDEV scope, so I wrap up here.

OK, so just for completeness: There are GPS receivers out there which can be configured with some rule to derive local time from GPS/UTC, including automatic switching to/from DST, and the local time can be output via different means.

As you have no doubt discovered by now, there is nothing simple about counting time :wink:

from the simple month/day versus day/month ambiguity to Einstein’s simultaneity thought experiment results - which result in special and later general relativity - time is hard to observe and harder to count!

and lawyers are especially bad at doing it - except in the special case of tallying how much of it that they have spent on your behalf and therefore how much you owe.

there may be nothing that you can do against monuments of stupidity, but the absolute rule is simple - time values that get stored persistently, should be stored in UTC. and then displayed in whatever local time is appropriate.

1 Like