6 ms·
Why wouldn't you just use epoch time?
by bzbz 7y ago
Why wouldn't you just use epoch time?
- eyelidlessness 7y ago1. It is lower fidelity (seconds vs milliseconds). 2. It's also not a type. How do you distinguish epoch from number?
- Minor49er 7y ago1. You could use a float. 2. Probably in the documentation of whatever it is that's using it
- nitrogen 7y agoEpoch floats and doubles are not good for timestamps, as the further we get from 1970 the less precise they become. Current precision with a 32-bit float (JSON/JavaScript are 64-bit usually, though in non-JS it's common to use Bigdecimal in slight non-compliance) is much worse than one second.
- ci5er 7y agoFloats are ugly because the distance between any two successive numbers are not the same. This makes them inappropriate for discretized time and anything accounting-related (money).
- stickfigure 7y ago> in the documentation of whatever it is that's using it That's the point, timestamps should be self-describing. If "look up the structure in documentation" suffices we might as well just use protobufs.
- eyelidlessness 7y ago1. YUK 2. ISO 8601 is a better format for this.
- a1369209993 7y ago> It's also not a type. How do you distinguish epoch from number? I dunno, how do you distinguish "April" (the month) vs "April" (someone's first name) or 18 (kg) vs 18 ($) vs 18 (-th of the month) vs 18 (page number)? > It is lower fidelity (seconds vs milliseconds). This isn't a problem if you have a conforming implementation (2^52 milliseconds is over 100'000 years), but as nitrogen pointed out, you do apparently have to worry about that.
- HereBeBeasties 7y agoWhat the original poster means is that if I go JSON.parse(...) then how does that know to give me an object with a Date type instead of a Number? Answer: It can't. This is a frequent gotcha with Typescript, where even if your type is declared with a Date field, Javascript won't care when it deserializes it, as that type information is all erased and not available at runtime. (Also, Number in JS being floating point and all, it lacks the integer precision for high resolution timestamps - if you start serialising 64 bit timestamps and expect a JS-style runtime to do good things with them it doesn't end well.)
- a1369209993 7y ago> how does that know to give me an object with a Date type instead of a Number Ah, thanks, that makes sense; I'd forgotten that Javascript had a built-in Date type. (Strictly speaking, then, you ought to be able to write something like `{"time":new Date(...)}`, but that obviously doesn't work in practice.)
- eyelidlessness 7y agoSince Typescript is mentioned, might as well mention the awesome io-ts[1] library. It gives you both runtime validation and static type safety with very simple syntax. [1]: https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts
- eyelidlessness 7y ago> I dunno, how do you distinguish "April" (the month) vs "April" (someone's first name) or 18 (kg) vs 18 ($) vs 18 (-th of the month) vs 18 (page number)? Types! Extensible types. Like I said above, Transit is a good solution to this. With a fixed set of types, arbitrary data will always have ambiguity.
- foepys 7y agoEpoch doesn't carry timezone information.
- masukomi 7y agoepoch is INHERENTLY timestamped it's seconds since January 1, 1970 (midnight UTC/GMT). it'd be useless if it was just "you know midnight _somewhere_ on Jan 1 1970... pfft it was a long time ago. who cares"
- lucasmullens 7y agoWhen you go one hour back for daylight savings, you can't tell with just epoch if it's the first or second time you're at that time. With timezones you can, since it switches between PST and PDT.
- wahern 7y ago1:30PST and 1:30PDT bijectively map to distinct UTC timestamps.
- alpaca128 7y agoI don't know that much about epoch, but isn't the point of it to be completely independent of stuff like timezones or daylight savings? Doesn't it track every second since 1970 no matter if meanwhile time jumped back or forward in some countries?
- CameronNemo 7y agoUTC has leap seconds, but otherwise this is correct.
- kyralis 7y agoThis is fundamentally incorrect. Because UTC doesn't change, the two "identical" times are different UTC values.
- VMG 7y agoaside from the other issues mentioned here, alternative encodings like ISO8601 and others are human-readable and human-editable
- BurningFrog 7y agoThat's a timestamp, not a date. Maybe OP meant timestamp, but that's not what they wrote.