30 ms·
I like your premise but disagree with your guidance. You should not convert the integer early, you should actually wait until the very last moment. Nowadays a
by theK 3y ago
I like your premise but disagree with your guidance.
You should not convert the integer early, you should actually wait until the very last moment.
Nowadays a timestamp will be marshalled and demashalled by (at the very least) two runtimes until it reaches human eyeballs opening up a wide spectrum of bug potential, difficult to understand code and development slowdowns. Keeping it simple and unambiguous is very important. Time libraries have a habit of coming and going, ints are always there and 99% of the date arithmetic is trivial any way.
Don't use a lib, just pretty print numbers and you'll be fine.
- fluoridation 3y agoAn int is not unambiguous, though. "2023-11-19T14:22:34-03:00" is clearly a timestamp and represents an unambiguous point in time, while a number by itself doesn't mean anything. You have to know that it's a timestamp (probably from context) and you have to know what timezone it's in.
- Dylan16807 3y ago> You have to know that it's a timestamp So what? That's true of all formats. How is it relevant to the choice of which format to use at which stage of the process? > and you have to know what timezone it's in. You don't. > clearly a timestamp Not very helpful. It's easy to set up types in advance. Don't figure out if things look like timestamps at parse time, or you'll be causing the same problems that turn gene names into dates and choke on people named Null.
- Izkata 3y agoThat datetime is unambiguously represented by 1700414554 as a unix timestamp, and you'd convert to the user's local time zone on display.
- pletnes 3y agoIt’s a nightmare for the backend developers, compared to iso-strings, in my experience.
- rusk 3y agoNot in the future it’s not. There’s no way to know the exact epoch time until it has happened. Timestamps “float” and can accommodate local fluctuations or even changes.
- theK 3y agoI have never heard of epoch time "floating" any links?
- rusk 3y agoHaha. I’m sorry if the terminology is catching you out. It’s not epoch time that floats. Epoch time is an inalienable absolute (at least in theory). However actual cosmological and time as perceived by humans does drift wrt to epoch time. Which of these is right is a philosophical discussion but at the present instant they do indeed converge and so epoch time between now and some time in the early 1960s is “the correctest” from a systems perspective.
- jagged-chisel 3y agoBut 1700414554 is not unambiguously a date. Could be a count. Or an identifier. It needs metadata to tell you how to interpret it. For this to represent a datetime, the human needs to know that it’s a datetime, and what epoch and timezone to use. The ISO date string removes the ambiguity because the context for interpreting it is within the string.
- yen223 3y agoCrucially, that number could represent the number of seconds, or the number of milliseconds since Unix epoch (e.g. Date.getTime() in Java) You kinda have to guess from context that if it's a 10-digit number, it's probably seconds.
- theK 3y agoFair point, types should be documented, but them again that's hardly a requirement nowadays, right?
- bornfreddy 3y agoI never understood this argument. The ISO8601 date string is as much a convention as a unix timestamp is - without context neither are decipherable. If anything, unix timestamp is easier to explain to an alien than a date string. It has a starting point (1970/01/01 00:00 UTC) and it counts seconds from then. Care to explain how an ISO8601 date string is constructed? Also calculating amount of time between two ISO8601 strings without libraries is nor trivial, or any other operation actually. When dealing with dates, there is only one simple way to work with non-localized times, and it's not ISO-something. EDIT: > ...and what epoch and timezone to use. This is also not correct. Unix timestamp has a well defined epoch and it doesn't deal with timezones (though the epoch itself is, of course, usually defined as 1970/01/01 00:00:00 UTC). You are free to define other timestamps, but unix timestamp is well defined.
- mulmen 3y agoSeconds since epoch requires careful and precise handling of datatypes and assumptions. This works great inside a system where that can be managed but for the purpose of exchange between systems the ISO formats contain all relevant information. Either side can use a library to parse the string into their local representation. Comprehension by extraterrestrial life is a localization problem.
- mulmen 3y agoWhat library did you use? What is your epoch? Are those seconds or milliseconds? Is it UTC or TAI? ISO8601 and friends are literally for formatting dates for the purpose of exchange.
- theK 3y agoThe good thing about ints is that typically the stdlibs themselves deliver quite good tooling to work with Unix timestamps so in most cases you don't really use a library for the timestamps themselves.
- fluoridation 3y agoYou're assuming everyone is using the same standard library as you. Not every library uses even the same indivisible unit to tell time.