General > General Technical Chat
DateTime: as usual Randall Monroe is clued up
themadhippy:
--- Quote ---Let's see. Balloons
--- End quote ---
so it wasnt a weather balloon causing problems earlier this year,it was a chinese stock trader .
Nominal Animal:
Time is not something we can measure directly, only elapsed time; and in different locations, between any two events, the elapsed time varies. In some extreme cases, even the observed order of cause and effect can be reversed.
There are different classes of problems stemming from this. The nastiest one, I believe, is synchronization: consider GPS, or communication with space probes.
There are several clocks, or timekeeping bases, we use here on Earth. The most common is UTC or Coordinated Universal Time, based on TAI or International Atomic Time, with leap seconds added or subtracted as needed. (Thus, one minute can be 59 to 61 seconds long, even though almost all minutes are 60 seconds long.)
Unix time as used on most computers is based on UTC.
It is notable that TAI is the average of over 450 atomic clocks all over the Earth, so it does not represent the elapsed time on any point, but the average elapsed time on the surface of Earth since a preset epoch, that epoch itself purely notional (not physically verifiable or measurable at all).
To convert from UTC to local time, you need two databases: one is the leap second adjustment table (identifying when leap seconds were added or removed), and the other is the local time database including daylight saving times. You need the leap second adjustment table even for counting the exact number of seconds between two UTC date-times.
All this means is that our timekeeping is not, and cannot be exact.
Realizing this helps, because then you start thinking about what kind of precision is useful. And then, the timekeeping related problems start falling into different categories (depending on how important they are to the problem at hand), becoming just another numerical/physical (as opposed to algorithmic/theoretic) problem to be solved.
In numerical physical simulations with discrete time steps – involving anything from individual atoms, to stars and galaxies –, one key "trick" is to dynamically adjust the time step size to the scale at which events can be represented at useful precision. (It makes it MUCH harder for us humans to observe the time evolution of the system, though; our brains cannot really deal with time "speeding up" or "slowing down".)
In many cases from programming to humans waking up from sleep, the exact moment something is scheduled to happen in the future is less important than that moment being suitable. (You want to wake up from non-REM sleep, because waking up from REM sleep leaves you groggy. You don't want your computer to do housekeeping stuff like checking for updates while you're working or watching media full-screen, because it leads to jerkiness or added latencies.)
All this leads to moving away from "do X at time Y", into "do X after time Y1 but before time Y2": moving away from specific moments or points in time, into time intervals.
When you start really working with different aspects of time, it starts changing the way you think about it. (In a good way, I believe.)
tggzzz:
--- Quote from: Nominal Animal on December 14, 2023, 03:38:12 pm ---Time is not something we can measure directly, only elapsed time; and in different locations, between any two events, the elapsed time varies. In some extreme cases, even the observed order of cause and effect can be reversed.
There are different classes of problems stemming from this. The nastiest one, I believe, is synchronization: consider GPS, or communication with space probes.
--- End quote ---
In a distributed system there can be no common concept of time, and the best you can achieve is partial ordering.
Leslie Lamport's seminal papers had something to say about that back in 1978 :) http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf
He won a Turing Award for that! https://amturing.acm.org/award_winners/lamport_1205376.cfm
As for dates, realise that (amongst many many wierdnesses):
* in the UK the date 5th September 1752 simply does not exist[1]
* years have not always started on January 1st, even in Europe. 1751 in the UK (and the eastern bits of what has become the USA) was only 282 days long
[1] I first came across this when I was about 10yo. I read a story where some kids were able to prove a document was a forgery because it was dated 5th September 1752.
bill_c:
Tom Scott about date and time.
Nominal Animal:
--- Quote from: tggzzz on December 14, 2023, 03:58:07 pm ---
--- Quote from: Nominal Animal on December 14, 2023, 03:38:12 pm ---Time is not something we can measure directly, only elapsed time; and in different locations, between any two events, the elapsed time varies. In some extreme cases, even the observed order of cause and effect can be reversed.
There are different classes of problems stemming from this. The nastiest one, I believe, is synchronization: consider GPS, or communication with space probes.
--- End quote ---
In a distributed system there can be no common concept of time, and the best you can achieve is partial ordering.
Leslie Lamport's seminal papers had something to say about that back in 1978 :) http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf
He won a Turing Award for that! https://amturing.acm.org/award_winners/lamport_1205376.cfm
--- End quote ---
Exactly!
Authentication on the interwebs is a perfect example. From the server point of view, there is no ordering to the requests a specific client makes, and they can even be interspersed (as in more than one concurrent page load, with additional requests loading associated files, all at the same time). You cannot update the authentication information on each request, because each response can generate more than one request, and there is still no ordering. You can keep all information on the server, so that the authentication cookie is just a large random number with zero information in it, but that means servers need to share the same active authentication database. Instead, some kind of time-dependent field is used in the cookie.
Because there is no common concept of time, regardless of the validity duration of the time-dependent field (say, if it is in minutes, hours, or days, or anything in between), the server side has to be ready to accept the previous and the next value of said field –– either both, or previous for the first half of the validity interval, and next for the latter half of the validity interval.
There is no "today"; one must consider "yesterday", "today", and "tomorrow" concurrently.
Then, you add to the fact that sometimes, it is possible for the client IP (IPv4 especially, much less so for IPv6) address to change during an authorized session. How do you make sure it is not just an authentication cookie hijacking? If you include the client address or hash of the client address in the authentication cookie, you can detect when that (IP address change, or cookie replay/hijack attack) happens. Time, or order of events is not something you can really rely on, but a backup cookie that has not been used since authentication (limited by cookie path) can be of use. (If an attacker has the entire client browser state, they're in full control of the session anyway.)
Ones normal sequential view of time just doesn't work here; one must really understand intervals and how event ordering can vary.
And, whenever dealing with secure stuff, how event ordering can be exploited. CVE-1999-0035 is a good example of that: the good ol' ftpd SIGINT bug, which allowed superuser file access to a server just by sending Ctrl+C at the right moment, because ftpd developers didn't realize what might happen if the signal was delivered at just the right moment.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version