4 ms·
Nope, use ISO 8601 format just like blog post suggested. It's more readable and not vulnerable to the Year 2038 problem [1]. It's also important to note that I
by lightblade 11y ago
Nope, use ISO 8601 format just like blog post suggested. It's more readable and not vulnerable to the Year 2038 problem [1].
It's also important to note that ISO 8601 format is the default format that Date object serialize to. Try it new Date().toJSON()
[1]: https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem
- cbd1984 11y agoUnix timestamps aren't vulnerable to the Year 2038 Problem unless you deliberately make it so they are.
- tdeck 11y agoThe problem with ISO 8601 is that it isn't as simple as it looks. A lot of implementations that claim to support ISO 8601 do not parse all the different formats allowed by the standard. There are all kinds of weird edge cases like specifying a date with a year and week number that are valid. RFC3339 defines a subset that is only the sane tinestamp format most people probably think of when they think ISO8601. It's a good alternative, although a lot of the time UNIX timestamps are honestly the most convenient option for everyone. Source: spent a bunch of time designing a public API and thinking about this.
- deleted 11y ago[deleted]
- kbart 11y ago"It's more readable and not vulnerable to the Year 2038 problem" What makes you use signed 32-bit Integer for Unix timestamp in this age and day? I work with embedded systems and use Unix timestamp extensively, but never have I found any serious reason to use it as int32_t.