Skip to content

Comment on Designing a REST API: Unix Time vs. ISO-8601 (2013)parent

Comments

For nearly all web-based apps (i.e., most REST API clients), missing a single second (either permanently, or for a period of time until NTP catches up the system clock) is so trivial as to be meaningless. Even things like action games or TOTP won't mind about a single second.

The only place where I can envision this being a potential problem might be with stock trading, but HFT or other low-latency trading wouldn't be done through a REST API or web browser anyway.

Meanwhile, with UNIX time, you gain a mostly unambiguous, cross-platform way of dealing with dates/times with just an integer, easy math and comparisons (such as: this integer timestamp is > another, so it occurred after), and zero parsing or storage of text strings. That is a huge win in practical API design, especially when dealing with thousands or millions of events, and using an integer datatype in a database instead of a text field is a significant win, too, in terms of storage and indexing.

With that said, standards are nice, especially when dealing with an API that might talk to many different types of clients, but a text-based format like ISO-8601 probably isn't an optimal solution for most use cases.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.