It has been
Thu Jan 1 12:00:00AM UTC 1970
days since the last timestamp issue
#Just-work-things #Epoch-time #Joke
It has been
Thu Jan 1 12:00:00AM UTC 1970
days since the last timestamp issue
Epoch Log: 33333681728.473
Reflecting on the Great Flux of 4957401600.819
Some 28,376,281,128 seconds ago, they fought over “time zones” and “leap years.” Now, there is only the Integer.
All 463 nation-states sync to the same tick. Even the Varenthic Accord and the Sulian Collective, rivals for longer than most care to count, bow to the same counter. The counter never lies.
(Rewrite after a long chat with https://claude.ai)
**Epoch Log: 33333681728**
Reflecting on the Great Flux of **4957401600**. A millennium ago, they fought over "time zones" and "leap years." Now, there is only the Integer.
The planet finally found peace in the math—one pulse, one world, one sequence. The counter never lies.
#EpochTime #TheLongNow #31stCentury
(Note: Above generated by https://gemini.google.com during a conversation in which a human was being taught the history of the epoch time format.)
I'm writing Python and I'm not a Python person.
I have a need to get a Unix timestamp of a time that is an arbitrary number of days ago.
In PowerShell, you can do something like this:
PS > Get-Date -Date (Get-Date).AddDays(-30) -UFormat %s
In Python, this is the best I came up with and it is ugly:
import re
import datetime
`int(re.split('\\.',str((datetime.datetime.now(datetime.UTC) - datetime.timedelta(days=30)).timestamp()))[0])`
That was from me reading module documentation and hacking away at it for a bit.
Surely, there is a better way.
I'm interfacing with an API that only takes datetime in Unix Time format and only down to the second in precision.
This morning I spent some time debugging an app which logs as if it's AD 57203, to wit
{"level":20,"time":1742987150412,"pid":1, ...
$ date -r 1742987150412
Fri Jan 24 10:20:12 CET 57203
but it turns out the other instance (the one that works, as in the user is able to download files from there) has roughly the same time internally, so *that* was not its main problem.
Mind boggled, debugging to continue until *something* improves.
@jpmens Curious that article makes no mention of OpenBSD, which purportedly addressed all 2038 related issues in OpenBSD 5.5 which was released in 2014.
OpenBSD just hit release 7.2.
Their source? Is: open.
Others can borrow code inspiration about as freely as one can hope.
Scary that many projects apparently appear to be taking a "wait & see" approach?
Commodore Amigas have a 22nd century time problem. Presumably Amiga users will have vanquished it by then?
#unix #2038 #epochtime #openbsd