5 ms·

For sharing between systems and representing dates to humans debugging a system, the following has worked well … Planned local events: future date and time str

For sharing between systems and representing dates to humans debugging a system, the following has worked well … Planned local events: future date and time string including local time zone Planned global events: future date and time string in UTC, with UTC timezone Past events: date and time string in UTC with UTC time zone, unless there is a strong case to be made that these should be localized (see “planned local events” above) Strings in the format specified by ISO-8601. Of course, internal representation can be whatever it needs to be for efficiency. For example, maybe your database stores as integer microseconds since an epoch. Fine, but as soon as that leaves the database, ISO-8601 that date.

theK 3y ago
I like your premise but disagree with your guidance. You should not convert the integer early, you should actually wait until the very last moment. Nowadays a timestamp will be marshalled and demashalled by (at the very least) two runtimes until it reaches human eyeballs opening up a wide spectrum of bug potential, difficult to understand code and development slowdowns. Keeping it simple and unambiguous is very important. Time libraries have a habit of coming and going, ints are always there and 99% of the date arithmetic is trivial any way. Don't use a lib, just pretty print numbers and you'll be fine.
- fluoridation 3y ago
  An int is not unambiguous, though. "2023-11-19T14:22:34-03:00" is clearly a timestamp and represents an unambiguous point in time, while a number by itself doesn't mean anything. You have to know that it's a timestamp (probably from context) and you have to know what timezone it's in.
  - Dylan16807 3y ago
    > You have to know that it's a timestamp So what? That's true of all formats. How is it relevant to the choice of which format to use at which stage of the process? > and you have to know what timezone it's in. You don't. > clearly a timestamp Not very helpful. It's easy to set up types in advance. Don't figure out if things look like timestamps at parse time, or you'll be causing the same problems that turn gene names into dates and choke on people named Null.
  - Izkata 3y ago
    That datetime is unambiguously represented by 1700414554 as a unix timestamp, and you'd convert to the user's local time zone on display.
    - pletnes 3y ago
      It’s a nightmare for the backend developers, compared to iso-strings, in my experience.
    - rusk 3y ago
      Not in the future it’s not. There’s no way to know the exact epoch time until it has happened. Timestamps “float” and can accommodate local fluctuations or even changes.
      - theK 3y ago
        I have never heard of epoch time "floating" any links?
        rusk 3y ago
        Haha. I’m sorry if the terminology is catching you out. It’s not epoch time that floats. Epoch time is an inalienable absolute (at least in theory). However actual cosmological and time as perceived by humans does drift wrt to epoch time. Which of these is right is a philosophical discussion but at the present instant they do indeed converge and so epoch time between now and some time in the early 1960s is “the correctest” from a systems perspective.
    - jagged-chisel 3y ago
      But 1700414554 is not unambiguously a date. Could be a count. Or an identifier. It needs metadata to tell you how to interpret it. For this to represent a datetime, the human needs to know that it’s a datetime, and what epoch and timezone to use. The ISO date string removes the ambiguity because the context for interpreting it is within the string.
      - 3y ago
Izkata 3y ago
> Past events: date and time string in UTC with UTC time zone, unless there is a strong case to be made that these should be localized (see “planned local events” above) I don't think there's any case for storing local time with past events. They happened at a specific date and time, store them in UTC and if needed convert to local on display. Plus, though it's a rare circumstance, for one hour each year DST switches cause a duplicate hour - so local time is ambiguous during that hour.
- Ndymium 3y ago
  There is, when you aggregate your data to create graphs such as "My most active hours", you will have a problem if your user moves between timezones, if you did not store the actual local wall time. [0] For those cases, you can store the offset or the denormalized local time along with the UTC version. [0] https://blog.nytsoi.net/2022/03/13/utc https://blog.nytsoi.net/2022/03/13/utc

theK 3y ago

I like your premise but disagree with your guidance. You should not convert the integer early, you should actually wait until the very last moment. Nowadays a timestamp will be marshalled and demashalled by (at the very least) two runtimes until it reaches human eyeballs opening up a wide spectrum of bug potential, difficult to understand code and development slowdowns. Keeping it simple and unambiguous is very important. Time libraries have a habit of coming and going, ints are always there and 99% of the date arithmetic is trivial any way. Don't use a lib, just pretty print numbers and you'll be fine.

fluoridation 3y ago
An int is not unambiguous, though. "2023-11-19T14:22:34-03:00" is clearly a timestamp and represents an unambiguous point in time, while a number by itself doesn't mean anything. You have to know that it's a timestamp (probably from context) and you have to know what timezone it's in.
- Dylan16807 3y ago
  > You have to know that it's a timestamp So what? That's true of all formats. How is it relevant to the choice of which format to use at which stage of the process? > and you have to know what timezone it's in. You don't. > clearly a timestamp Not very helpful. It's easy to set up types in advance. Don't figure out if things look like timestamps at parse time, or you'll be causing the same problems that turn gene names into dates and choke on people named Null.
- Izkata 3y ago
  That datetime is unambiguously represented by 1700414554 as a unix timestamp, and you'd convert to the user's local time zone on display.
  - pletnes 3y ago
    It’s a nightmare for the backend developers, compared to iso-strings, in my experience.
  - rusk 3y ago
    Not in the future it’s not. There’s no way to know the exact epoch time until it has happened. Timestamps “float” and can accommodate local fluctuations or even changes.
    - theK 3y ago
      I have never heard of epoch time "floating" any links?
      - rusk 3y ago
        Haha. I’m sorry if the terminology is catching you out. It’s not epoch time that floats. Epoch time is an inalienable absolute (at least in theory). However actual cosmological and time as perceived by humans does drift wrt to epoch time. Which of these is right is a philosophical discussion but at the present instant they do indeed converge and so epoch time between now and some time in the early 1960s is “the correctest” from a systems perspective.
  - jagged-chisel 3y ago
    But 1700414554 is not unambiguously a date. Could be a count. Or an identifier. It needs metadata to tell you how to interpret it. For this to represent a datetime, the human needs to know that it’s a datetime, and what epoch and timezone to use. The ISO date string removes the ambiguity because the context for interpreting it is within the string.
    - 3y ago

Izkata 3y ago

> Past events: date and time string in UTC with UTC time zone, unless there is a strong case to be made that these should be localized (see “planned local events” above) I don't think there's any case for storing local time with past events. They happened at a specific date and time, store them in UTC and if needed convert to local on display. Plus, though it's a rare circumstance, for one hour each year DST switches cause a duplicate hour - so local time is ambiguous during that hour.

Ndymium 3y ago
There is, when you aggregate your data to create graphs such as "My most active hours", you will have a problem if your user moves between timezones, if you did not store the actual local wall time. [0] For those cases, you can store the offset or the denormalized local time along with the UTC version. [0] https://blog.nytsoi.net/2022/03/13/utc https://blog.nytsoi.net/2022/03/13/utc