Hacker News Reader

Comment by postalrat | Hacker News Reader

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.

View on HN

My 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.

Unix timestamps aren't human readable

Use better tools.

What do you use when you debug XHR in chrome?

Or what do you use to tail logs?

most logfiles beg to differ. (bleh!)

they're also... unix ... timestamps.

An ISO date with timezone can be useful, if you would like to know the timezone when a particular bit of data was recorded.

If 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.

Well, 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.

2038 called, they'd like to talk.

Javascript numbers (as in JSON) can safely represent integers much higher than a 32 bit integer.

Ha! 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.

Reply on news.ycombinator.com