4 ms·

Everything with timezones in a disaster, and the solution always seems to be a unix timestamp that is converted to human readable form at the last possible mome

by tdy721 11y ago

Everything with timezones in a disaster, and the solution always seems to be a unix timestamp that is converted to human readable form at the last possible moment...

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 ago
  Unix timestamps aren't vulnerable to the Year 2038 Problem unless you deliberately make it so they are.
- tdeck 11y ago
  The 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.
colanderman 11y ago
Unix timestamps cause a barrel of fun when leap seconds roll around. See e.g. https://access.redhat.com/articles/15145#known https://access.redhat.com/articles/15145#known Trivia: "Unix time" is not seconds since midnight January 1, 1970 UTC. It in fact represents the number of full days since January 1, 1972 UTC, plus 730, times 86400, plus the number of seconds since midnight. Due to this definition, it is not monotonic, as it may occasionally have discontinuities of 1 second (in either direction!) due to leap seconds. Best is to just count seconds since some epoch (e.g. Unix time based on TAI rather than UTC), but not many systems actually do this.
- Johnny_Brahms 11y ago
  We were bitten by this once, and we ended up relying on TAI and then making leap second deviations _very_ clear to users. I never really got what the problem was, but apparently someone had been careless about comparing times on some transaction which ended up giving a client a bad day. This was some time ago, and if this stuff actually matters to you you probably know how to deal with it.

by tdy721 11y ago

Everything with timezones in a disaster, and the solution always seems to be a unix timestamp that is converted to human readable form at the last possible moment...

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 ago
Unix timestamps aren't vulnerable to the Year 2038 Problem unless you deliberately make it so they are.
tdeck 11y ago
The 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.

colanderman 11y ago

Unix timestamps cause a barrel of fun when leap seconds roll around. See e.g. https://access.redhat.com/articles/15145#known https://access.redhat.com/articles/15145#known Trivia: "Unix time" is not seconds since midnight January 1, 1970 UTC. It in fact represents the number of full days since January 1, 1972 UTC, plus 730, times 86400, plus the number of seconds since midnight. Due to this definition, it is not monotonic, as it may occasionally have discontinuities of 1 second (in either direction!) due to leap seconds. Best is to just count seconds since some epoch (e.g. Unix time based on TAI rather than UTC), but not many systems actually do this.

Johnny_Brahms 11y ago
We were bitten by this once, and we ended up relying on TAI and then making leap second deviations _very_ clear to users. I never really got what the problem was, but apparently someone had been careless about comparing times on some transaction which ended up giving a client a bad day. This was some time ago, and if this stuff actually matters to you you probably know how to deal with it.