> On Tue, 12 Nov 2024 at 15:53, tsiegel--- via Freedos-user > > > > To solve the whole time/date problem, I never understood why they > > don't separate the two. Time could then be a regular integer, since > > there's only 86,400 seconds in a day. > Hmm. I have to give this idea some credit, in the context of terminology. A date is what consists of YYYY-MM-DD, so time can mean the finer fractions.
Other than that, there is no single encoding that will suit everybody... No matter what you propose, you'll always find someone for whom your chosen integer data type is too long, and someone for whom the resolution is not enough - be it days, milliseconds or nanoseconds. Therefore, inevitably, the math of comparing two timestamps or adding an interval to a timestamp will sometimes entail carry transfer operations... depending on circumstances. > Hint. There are 24 timezones, but not all are 1 hour different. > Computers move. Sometimes they move fast. Computers fly aeroplanes and > sail ships. They move across timezones and need to keep working. > > Go read this, and I mean all of it, closely. It is fun, it is > interesting, and it will teach you stuff you NEED to know. > > https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca > That list is hilarious - thanks Liam, didn't know that one :-) That said, I find it spooky to the casual reader. Let me follow up on a more constructive note: There is the UTC, as a reasonably useful and reliable global standard. A popular common denominator. Operating systems (definitely other than DOS), namely UNIX and NT-based Windows, run in UTC on the inside. Local time zones are a matter of user interfaces / presentation layer. A logged-in desktop (or the machine as a whole?) has a "locale", including a timezone name and offset, that can be changed without messing with the one system clock under the hood running UTC. If you want your software to be immune from local timezone shenanigans, use UTC internally for your timekeeping. The one time sync protocol in the Internet, the Network Time Protocol, also runs in UTC, per standard. Thus, the timekeeping services in operating systems can talk to each other in the same time domain in which they internally operate. So again UTC is a common denominator, throughout the global internet, cross platform (speaking of computer operating systems). UTC is still made interesting by leap seconds. In practical operating systems, these are forever an element of fun. I could go into detail but I do not want to. To most people and systems, leap seconds are a random nuissance that hopefully does not cause much damage. I could quote examples to the contrary, but I don't think this is the right place :-) Apart from UTC, there are other time "domains", such as GPS time and TAI. These two run without leap seconds. GPS time is shifted by a couple seconds vs. the TAI. Only UTC has leap seconds - when a leap second occurs, the offset of UTC vs. TAI and GPS time gets incremented (or decremented). In this context, UTC is the "convenient human wall time". TAI is the domain in which the official reference atomic clocks really tick, united and organized by a body called BIPM. TAI is also used for industrial applications - such as, the Precision Time Protocol uses TAI by default. The advantage of TAI is exactly that every minute is always 60 seconds long and there are no "leaps" (anomalies) to that rule. The occasional decision to introduce a leap second is based on science, but also has a significant political angle. Cannot be algorithmized - it just has to be absorbed by the system when it happens. Having a "non-leaping" machine-oriented time domain like the TAI makes it easy to implement or consider UTC merely as an integer offset off the TAI (similar to the local timezone offsets). Inside operating systems, as a programmer, you can meet several nominal "time domains" that differ in fine timing details: - there's the CLOCK_REALTIME which corresponds to the UTC. The OS timebase keeps this clock long-term accurate by finely adjusting the frequency of its ticking, by periodically reprogramming some hardware divider or synthesizer (that internally runs along a relatively imprecise bus-clock crystal as its reference frequency). If a large offset is encountered, CLOCK_REALTIME can also jump = get adjusted stepwise. - there's also the "CLOCK_MONOTONIC" which is useful as a "relative" timing source that never jumps. It is possibly frequency-adjusted along UTC. And there's a CLOCK_MONOTONIC_RAW that is closest to the hardware timebase, in that it does not even get frequency-adjusted. Operating systems or standard libraties contain functions to convert between inner representations of time that are close to some long integer type (UNIX "time_t" epoch time, Windows FILETIME) and human-oriented breakdown of the time information into YYYY-MM-DD HH-mm-SS.fraction . I cannot deny that there are application needs or practical situations in the life of a programmer, where anomalous reality needs to be accomodated, or at least error-checked and reported... see the link provided by Liam, the list looks exhaustive :-) Also, once you start tinkering with timekeeping, you will find out that accuracy and precision and synchronicity always have a limit (some minimal error/deviation/noise), that there are limits to how accurate your TDEV measurements can get, you run into "phase locked loop tuning" aspects (control theory), oscillator stability and ageing etc. Signal paths and logic gates feature transport delays that are fixed but not always known. Even just the operation of "taking a timestamp" in software entails processing latencies that are not necessarily constant and symmetrical, between your software thread and the HW clock whom you are asking... No need to despair. What sort and level of imperfections actually bother you, always depends on the application or assignment at hand... It is fun :-) Frank _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
