4 ms·

I think you're mixing up a few different causes and concepts. Wristwatches are generally accurate and can generally be relied upon. It's not practical or reaso

I think you're mixing up a few different causes and concepts. 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.

hilbert42 4y ago
"It's not practical or reasonable to say they should be a "last ditch resort" simply because they do not handle legislative corner cases." 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.
- throwaway09223 4y ago
  "if say computer languages had declarative statements and underlying mechanisms to separate internal and external clocks" 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.
  - hilbert42 4y ago
    Right, I'm not disagreeing with any of that except to say it's application is not ubiquitous and thus not universally applied despite the fact that it's part of a common O/S. 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).

hilbert42 4y ago

"It's not practical or reasonable to say they should be a "last ditch resort" simply because they do not handle legislative corner cases." 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.

throwaway09223 4y ago
"if say computer languages had declarative statements and underlying mechanisms to separate internal and external clocks" 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.
- hilbert42 4y ago
  Right, I'm not disagreeing with any of that except to say it's application is not ubiquitous and thus not universally applied despite the fact that it's part of a common O/S. 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).