4 ms·

ISO 8601 is bad, use RFC 3339. A lot of implementation are actually based on an ISO draft which changed in final release. But most dev do not have access to th

by kuon 5y ago

ISO 8601 is bad, use RFC 3339. A lot of implementation are actually based on an ISO draft which changed in final release. But most dev do not have access to the spec. For example, timezone can only be specified as offset in the standard, while implementations accept name. Globally avoid ISO for software, it is non free crap. Also, do not use those standard for dates with timezone in the future. Use wall time/date and location. As timezone can change way more often than you think.

idoubtit 5y ago
My own experience is that (unix) timestamps are much less error-prone than textual representations like ISO 8601 and such. A field like `update_time_seconds` is clear and easy to convert into any representation. This is what the Google API Improvement Proposals recommends in most cases, though civil timestamps are also described. https://google.aip.dev/142 https://google.aip.dev/142 Of course, when preparing queries against the API, you may need a helper to build valid timestamps. But this is mostly relevant to the discovery phase which isn't automated. And textual dates also have drawbacks, for instance the need to encode it when used a an URL parameter.
- kuon 5y ago
  I agree, for timestamp, I often use ms or sec offsets. But I do not dare say it because I pass for an old fool.
grishka 5y ago
Why use string-based timestamps at all? Use unixtime. It's much easier to parse and it literally can't be malformed.
- arendtio 5y ago
  Sometimes timezones or the like change. So for future dates, those textual represations are probably better. Example: in November you create an appointment in 6 months at 15h, but then your government decides, to not use summer time next year. If you use timestamps your appointment will be wrong by one hour (humans tend to keep the 15h). In general, I am a huge fan of timestamps, but I think it is good to know where they have their limits.
  - grishka 5y ago
    > Sometimes timezones or the like change. Why would you ever want anything to do with timezones in an API? Even for appointments, it's still a timestamp. Timezone should be applied the very last moment, as part of date formatting for output on the client. If you allow your users to create appointments this much in advance and then they miss them, it's a UX problem, not an API design problem.
    - nickkell 5y ago
      Why do you say appointments are a time stamp? They are made with humans in mind, people dealing with a local time zone. In the example in the post you’re replying to, the time zone change means the time stamp would be wrong by an hour. This doesn’t mean that people should show up an hour earlier or later than initially intended!
      - grishka 5y ago
        Because they are a timestamp. In an overwhelming majority of cases when you're going to deal with time in software, it's a timestamp. Timezones are a client's concern. You ask the user to input the time in their local timezone, then convert that to unixtime and send it to the server. Timezone isn't a simple constant offset either. For places that use DST, any decent date library would take that into account. If you entered a date in summer while it's winter, it would still result in a correct unixtime.
        detaro 5y ago
        Do you intentionally just ignore the point made about timezone changes?
        grishka 5y ago
        Well, how do operating systems handle this sort of stuff? With updates. When it's at all possible to update. There are many devices that don't receive any updates at all any more. There are some devices that weren't designed to be updatable to begin with. It's a necessarily manual process and it creates a lot of confusion either way. And it's sufficiently rare to ignore. And these changes tend to be announced in advance.

by kuon 5y ago

idoubtit 5y ago

My own experience is that (unix) timestamps are much less error-prone than textual representations like ISO 8601 and such. A field like `update_time_seconds` is clear and easy to convert into any representation. This is what the Google API Improvement Proposals recommends in most cases, though civil timestamps are also described. https://google.aip.dev/142 https://google.aip.dev/142 Of course, when preparing queries against the API, you may need a helper to build valid timestamps. But this is mostly relevant to the discovery phase which isn't automated. And textual dates also have drawbacks, for instance the need to encode it when used a an URL parameter.

kuon 5y ago
I agree, for timestamp, I often use ms or sec offsets. But I do not dare say it because I pass for an old fool.

grishka 5y ago

Why use string-based timestamps at all? Use unixtime. It's much easier to parse and it literally can't be malformed.

arendtio 5y ago
Sometimes timezones or the like change. So for future dates, those textual represations are probably better. Example: in November you create an appointment in 6 months at 15h, but then your government decides, to not use summer time next year. If you use timestamps your appointment will be wrong by one hour (humans tend to keep the 15h). In general, I am a huge fan of timestamps, but I think it is good to know where they have their limits.
- grishka 5y ago
  > Sometimes timezones or the like change. Why would you ever want anything to do with timezones in an API? Even for appointments, it's still a timestamp. Timezone should be applied the very last moment, as part of date formatting for output on the client. If you allow your users to create appointments this much in advance and then they miss them, it's a UX problem, not an API design problem.
  - nickkell 5y ago
    Why do you say appointments are a time stamp? They are made with humans in mind, people dealing with a local time zone. In the example in the post you’re replying to, the time zone change means the time stamp would be wrong by an hour. This doesn’t mean that people should show up an hour earlier or later than initially intended!
    - grishka 5y ago
      Because they are a timestamp. In an overwhelming majority of cases when you're going to deal with time in software, it's a timestamp. Timezones are a client's concern. You ask the user to input the time in their local timezone, then convert that to unixtime and send it to the server. Timezone isn't a simple constant offset either. For places that use DST, any decent date library would take that into account. If you entered a date in summer while it's winter, it would still result in a correct unixtime.
      - detaro 5y ago
        Do you intentionally just ignore the point made about timezone changes?
        grishka 5y ago
        Well, how do operating systems handle this sort of stuff? With updates. When it's at all possible to update. There are many devices that don't receive any updates at all any more. There are some devices that weren't designed to be updatable to begin with. It's a necessarily manual process and it creates a lot of confusion either way. And it's sufficiently rare to ignore. And these changes tend to be announced in advance.