Alt text:
It’s not just time zones and leap seconds. SI seconds on Earth are slower because of relativity, so there are time standards for space stuff (TCB, TGC) that use faster SI seconds than UTC/Unix time. T2 - T1 = [God doesn’t know and the Devil isn’t telling.]
We use datediff in sql and let God handle the rest.
“Oh but they’re in different time zones” “Oh did you account for if one is in day light savings and other isn’t” “Aren’t some of these dates stored in UTC and some local?”
Are all problems I do not care about.
This is why we should just move to a universal time zone and stop with the day light savings.
We have that, it’s called Unix time, and the only thing it doesn’t account for is time dilation due to relativity.
If your system hasn’t been upgraded to 64-bit types by 2038, you’d deserve your overflow bug
From the wikipedia:
TCB ticks faster than clocks on the surface of the Earth by 1.550505 × 10−8 (about 490 milliseconds per year)
It’s amazing that this level of detail is relevant to anything.
Without considering this, most people wouldn’t be able to drive anywhere they haven’t been before anymore.
“Wouldn’t be able to” is a bit of a stretch, since Thomas Maps existed long before GPS. But it wouldn’t be so easy as it is now.
I got to “The day before Saturday is always Friday” and I was like waaaa?
I thought it is about when Julian calendar was dropped in favour of Gregorian, but that’s not it:
Thursday 4 October 1582 was followed by Friday 15 October 1582
I really wish that list would include some explanations about why each line is a falsehood, and what’s actually true. Particularly the line:
The software will never run on a space ship that is orbiting a black hole.
If the author has proof that some software will run on a space ship that is orbiting a black hole, I’d be really interested in seeing it.
All links to the original article are dead and even archive.org doesn’t have a capture either. I guess the argument is along the lines of “it might not be relevant, when you’re scripting away some tasks for your small personal projects, but when you’re working on a widely used library or tool - one day, it might end up on a space vessel to explore whatever.”
E.g. my personal backup script? Unlikely. The Linux kernel? Somewhat plausible.
It’s a programmer thing. As you’re typing the code, you may suddenly realize that the program needs to a assume certain things to work properly. You could assume that time runs at a normal rate as opposed to something completely wild when traveling close to the speed of light or when orbiting a black hole.
In order to keep the already way too messy code reasonably simple, you decide that the program assumes you’re on Earth. You leave a comment in the relevant part of the code saying that this part shouldn’t break as long as you’re not doing anything too extreme.
This one is good (or evil, depends on how you see it):
Human-readable dates can be specified in universally understood formats such as 05/07/11.
Does anyone know what is untrue about “Unix time is the number of seconds since Jan 1st 1970.”?
When a leap second happens, unix time decreases by one second. See the section about leap seconds here: https://en.m.wikipedia.org/wiki/Unix_time
As a side effect, this means some unix timestamps are ambiguous, because the timestamps at the beginning and the end of a leap second are the same.
It might be more accurate to say that Unix time is the number of days since Jan 1st, 1970, scaled by 24×60×60. Though it gets a bit odd around the actual leap second since they aren’t spread over the whole day. (In some ways that would be a more reasonable way to handle it; rather than repeating a second at midnight, just make all the seconds slightly longer that day.)
Ah I’ve gotten to the point where I have to define what “frame” and epoch each time base is in before I’ll touch the representation of time( Unix,Gregorian, etc) .To be honest I’m probably just scratching the surface of time problem.
Hell probably the reason we haven’t seen time travellers is we suck at tracking time and you probably need to accurately know your time and place to a very good precision to travel to a given point and we can’t say where and when that is with enough accuracy to facilitate where to land. And people don’t want to land in the earth’s surface or 10000 km away from a stable orbit. Maybe some writer can build that out for a time travel book or to discount it for some reason lol
I recall a short story like that where someone died because they time traveled, but didn’t account for position.
Highly recommended
SPOILER
I want little Emily to change her future. A sequel is needed!
–
(Thanks for sharing, was a good watch.)
Then there’s continental drift, which as Indiana Jones reminded us this past summer, Archimedes didn’t know about when he built his time machine.
Pet peeve: brushing aside the time travel fantasy element, there is not a single shred of evidence of any type of connection between Archimedes and the Antikythera Mechanism.
As if the only person clever enough in Ancient Greece was that one famous dude from Syracuse.
Ionians: “Are we a joke to you?”
I just spent two days debugging a reporting endpoint that takes in two MM-YYYY parameters and tries to pull info between the first day of the month for param1 and the last day of the month for param2 and ended up having to set my date boundaries as
LocalDate startDate = new LocalDate(1, param1.getMonth(), param2.getYear()); //pretty straightforward, right?
//bump month by one, account for rollover, set endDate to the first of that month, then subtract one day
int endMonth = param2.month == 12 ? param2.month + 1 : 1;
LocalDate endDate = new LocalDate(1, endMonth, param2.year).minusDays(1);
This is extraordinarily simply for humans to understand intuitively, but to code it requires accounting for a bunch of backward edge/corner case garbage. The answer, of course, is to train humans to think in Unix epoch time.
Using YearMonth.atEndOfMonth would have been the easier choice there, I think
holy shit, yeah it would have. tyvm, I’ll be putting in a PR first thing monday!
Would you mind trying to explain (ELI5 style) what you did before and why you are excited for this new method for those of us who dont understand code?
In the example you gave, wouldn’t the year be off by one when param2.month is 12?
I was transcribing it from memory and that exact problem cost me like two hours when I was writing it the first time. Well spotted, now write me a unit test for that case.
Unix epoch time in UTC, making sure that your local offset and drift are current at the time of conversion to UTC…
All dates and times shall be stored and manipulated in Unix time. Only convert to a readable format at the top of the UI, and forget trying to parse user inputs :P that’s just impossible