My post about 19th C. timezones and train timetables is about this very point. All these independent systems are independent 'timezones' and that's the problem - and it's a fundamental one!

First, closed systems are intrinsically subject to drift and will never really be on time anyway. Second, there's nothing wrong with an independent closed system having a 'clock' - 'oscillator' would be a better word here - but it was all too convenient to couple this with external time systems. In essence, independent closed systems will never be in sync with external time.

If closed systems have to have time clocks that are an analog of real-world time then they should always be considered an approximation as with all analog systems. Relying on them for accuracy has to be a last ditch resort.

The trouble is that we never adopted this newer mindset from the outset of digital systems, instead we simply repeated the earlier mistake of every town having its own timezone.

There are ways around these problems just as there were in the 19th C. but no one has bothered to implement them.

This is not the place to delve into them except to say that they involve both technological solutions and an automatic assumption by humans that closed systems cannot be relied upon to provide accurate time.

Wristwatches are generally accurate and can generally be relied upon. It's not practical or reasonable to say they should be a "last ditch resort" simply because they do not handle legislative corner cases.

All clocks are approximations to some degree, because time and space are relative. This is true of all systems of measurement in science, in general.

It's not possible to have a computer perfectly account for all legislative corner cases for the same reason it's not possible to have a perfect map: Grey areas exist within law and geopolitics. Knowing the time requires knowing map boundaries and which authority controls a given area. For example: Does Ukraine observe DST? The Donbass region?

Furthermore there are practical costs associated with automatic clocks: A GPS, an updating map system and an updating database of time legislation is expensive to implement in terms of hardware, energy, etc.

These are not problems that no one's bothered to implement. They come at a cost which we aren't willing to shoulder, or in some cases are intractably complex social questions with simple pragmatic work-arounds (make the clock dumb and set it to whatever you wish)

In reality, close enough is often good enough. Perfection isn't necessary.

I essentially agree with this comment and most of what you've said. No doubt, in hindsight, I could have expressed the matter more clearly and succinctly.

What I should have stressed is that there should be a greater emphasis placed on the formal aspects of the problem (as opposed to day-to-day practicalities).

If from a computer science perspective we had a more clearly defined formalism in respect of time then programmers would be much more careful about time ambiguities and separating internal clock mechanisms from external ones.

I've not given this huge thought but if say computer languages had declarative statements and underlying mechanisms to separate internal and external clocks then some of these problems may be averted. This perhaps could be extended further by having any number of 'clock subsystems' and having a formal mechanism that defines (and or couples) the relationships between them.

If languages made these distinctions in clear, non ambiguous ways then they'd always be at the forefront of programmers' minds even if on most occasions those relationships were set to 1:1.

If one thinks about it this isn't as a preposterous idea as it may seem as the whole notion of relative time naturally falls out of Relativity/Spacetime.

Making computers and compter languages inherently aware of the fact would likely bring benefits. This, no doubt, would add upfront complexity but the payoff would come when dealing with problems of the type we've been discussing here.

Well, we actually do have those things. You're pretty much describing how the unix time APIs work today.

The internal unix clock is kept as a "time_t", "struct timeval", or "struct timespec", which is seconds, usec, or nsec since an epoch. This is largely insulated from the geopolitical nonsense -- though it is imperfect with respect to leap seconds and it should have been defined as TAI. This is specified in sys/time.h on linux . These are further separated into clocks like CLOCK_REALTIME and CLOCK_MONOTONIC, which track adjusted actual time (updated by ntp), and elapsed relative time respectively.

The "external clocks" as you call them are specified by the time.h functions like "ctime" or "localtime." These functions take the above internal clocks and apply timezone data to localize time to a specific area on earth.

"If one thinks about it this isn't as a preposterous idea as it may seem as the whole notion of relative time naturally falls out of Relativity/Spacetime."

Right, but we do this already. There's no such thing as a clock without a frame of reference though, so there will always be some special location in space/time which is the perspective of the system clock.

"Making computers and compter languages inherently aware of the fact would likely bring benefits. "

We already have reaped these benefits! The existing problems center around stuff like:

* Figuring out who's a correct relative authority for a given place on earth

* Communicating updates (and, correspondingly, guarding against bad updates)

* Figuring out how to keep various autonomous systems consistent

* Helping software developers understand these inherent complexities in timekeeping -- because I guarantee your average software developer is largely unaware that all these distinctions already exist.

If it were then the DST problem would not have arisen or that it would have been much easier and qicker to solve. (That is, not every one understands the issue to the point where it's no longer the subject of debate - ipso facto, the fact that we're having this debate on HN demonstrates that lack of universality.)

A similar system with a niche application which also possesses truly advanced relativistic timekeeping features is the software for GPS satellites. However it too hasn't been universally applied (needless to say, it'd also likely require extensive modification if it were to be adapted for the use that we're discussing here, that said, no doubt the basic algorithms would be adaptable).

The DST problem is due to the database that these interfaces use not being designed for rapid updates.