Question

This isn’t strictly a homework question, but an offshoot.

How are time functions implemented in object oriented languages and also imperative languages like C? If you were to obtain a timestamp in nanoseconds as a long and convert it to a string, wouldn’t the time always be inaccurate?

In fact, as soon as you do any computation or work with the timing data, isn’t it now inaccurate to some unknown degree? Is this assumption correct?

You can account for network latency pretty easily, but what about locally before the data is even sent? It seems that everyone asked so far has come to the conclusion that time functions are never completely accurate – it’s just an accepted inaccuracy.

Essentially, what I’m asking is how are real-world time applications implemented?

Answer 1

Actually homework!

The thing we call time progresses. A long time ago the thing
did not even carry numbers. Just the traveling sun and the traveling stars were giving
a hint about time. Later, particulary since the start of the digital revolution, Numbers
were assigned to time.
Progressing time comes along with incrementing numbers. Without saying much about all the
different formats I state that most of these schemes do have an orgin for the time. Unix epoche
is the time 00:00:00 UTC on 1 January 1970 for example. Of course this is not the beginning of time, but such virtual origins are choosen to fit the numbers into reasonable data structures.
Back to you question: Are we able the capture the current time at all? No we arn’t and we will never be able. Reading any clock will tell us the time at which the light has left the clock on its way to our eyes. It may be very little but…
When someone has asked us for the time, we are happy to tell. But again some delay occurs and I am sure we would tell the same time without adding the delay.

Knowing the physics we could add the delay for the light reaching our eyes, the delay our brain took and the delay our spoken words will need to reach the ear of the person asked.

But……….

So how can a real world time application be implemented? There is no THAT TIME. Time depends on where you are, time depends on what gravity surrounds you, time depends on your velocity, and so on.

But………

It is not that things are happening because the time passes by. No, time makes things happen!

Again back to your question: Generally in software matters, the question about time is basically a question about progress and/or synchronization. You want to compare to something.
Basically there are two possible calls to a resource which supplies this progress called time: The first call will return the time at the time you made the call. But you need to take into account that you’ll get the result later. So the time you’re getting is somewhat in the past. The second call returns the time at which the call returns. This is a slightly different implementation since such a function has to know something about how long it needs for its own service. This is likely only possible with some calibration.

Those are the two principal calls.

When it comes to resolution (again back to your question), I’d like to exclude the option to have an atomic clock connected to your computer. Let’s assume you’re owner of an
off the shelf super market computer. It may run at a few GHz. The highest frequency you may observe is likely the cpu frequency. At say 4GHz such a frequency will cause a counter to increment 4 times within a nanosecond, that is a 250 picosecond time resoltion. So generally you may say there is sub-nanosecond resolution. In practice the commonly used high frequency counters are in the MHz range, which will give resolutions in the 100ns units range.

But…….

Can these high frequencies be used as a ruler for time? On the short run they can! But on the long run it is much more complicated because those time sources have to be phase locked with common time sources like your pc time for instance. The high frequency counters do have significant errors which will cause a phase drift of many us/s. This can only be overcome by carefull calibration. A proper calibration may allow to phase lock the high frequency counter to the system time.

Once you have a time source at an accuracy in the few microseconds range you may diagnose the behavior of your code quite differently because you can predict potential latencies.

To summarize (a philosophical approach):

1. Time makes things happen.
2. Time is never true or represents a true value
3. Any value considered related to time represents a time in the past
4. There is no such thing actual time in practice
5. Finally, as you’re saying: Time can never be completely accurate (nothing can!)

A closer look at the implementation of high resolution time services for Windows can be found a the Windos Timestamp Project.