3 ms·
This may be unrelated but every time I see a timestamp as a string in json I wonder why. There is so much less to go wrong with a numeric unix timestamp yet 9 t
by postalrat 6y ago
This may be unrelated but every time I see a timestamp as a string in json I wonder why. There is so much less to go wrong with a numeric unix timestamp yet 9 times out of 10 a developer will use a string.
If you are going to make things strict at least make it hard to mess up.
- genidoi 6y agoUnix timestamps aren't human readable
- remus 6y ago2038 called, they'd like to talk.
- postalrat 6y agoJavascript numbers (as in JSON) can safely represent integers much higher than a 32 bit integer.
- Joker_vD 6y agoHa! Almost. You can get slight rounding errors at nanosecond resolutions, so be aware of this if you're using Go's time.Time internally and convert it to/from float64 seconds since Unix epoch.
- bartvk 6y agoAn ISO date with timezone can be useful, if you would like to know the timezone when a particular bit of data was recorded.
- crote 6y agoIf you mean ISO 8601 and its "2007-04-05T12:30-02:00" timezone thingy, not really. It doesn't store a timezone, but a UTC offset. Which is a problem because the UTC offset of a timezone may change. This happens rarely enough that people do indeed use "ISO 8601 + offset" to store "timezoned" timestamps, but often enough that it'll probably end up corrupting your data sooner or later.
- Joker_vD 6y agoWell, usually what you want is actully the UTC offset, not the timezone, because that's what you need to get the actual-wall-clock timestamp of the event. If you all you have is a timzeone, then you need an accurate historical tzdata and also you need to be sure that the system had accurate tzdata itself when it produced the timestamp. Of course, if you're storing the timestamp of a future, planned event, then yes, you need a timezone. But for historical records, store the UTC offset that was in effect when the event happened.
- shhsshs 6y agoMy 2 cents... For the vast majority of the world where legacy (or at least not-programmed-using-super-modern-standards) systems are still in play, clarity is the most important factor in software. What happens when a legacy system is actually returning the number of seconds since epoch versus milliseconds? What if they're returning ticks (looking at you .NET...) because nobody realized ticks are inconsistent across different systems at the time the system was written? I don't think you can get any more clear than an ISO timestamp (WITH time zone). Unix timestamps are great and efficient, but I personally value the absolute clarity of ISO above all else.