5 ms·

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 datet

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.

yen223 3y ago
Crucially, that number could represent the number of seconds, or the number of milliseconds since Unix epoch (e.g. Date.getTime() in Java) You kinda have to guess from context that if it's a 10-digit number, it's probably seconds.
- theK 3y ago
  Fair point, types should be documented, but them again that's hardly a requirement nowadays, right?
bornfreddy 3y ago
I never understood this argument. The ISO8601 date string is as much a convention as a unix timestamp is - without context neither are decipherable. If anything, unix timestamp is easier to explain to an alien than a date string. It has a starting point (1970/01/01 00:00 UTC) and it counts seconds from then. Care to explain how an ISO8601 date string is constructed? Also calculating amount of time between two ISO8601 strings without libraries is nor trivial, or any other operation actually. When dealing with dates, there is only one simple way to work with non-localized times, and it's not ISO-something. EDIT: > ...and what epoch and timezone to use. This is also not correct. Unix timestamp has a well defined epoch and it doesn't deal with timezones (though the epoch itself is, of course, usually defined as 1970/01/01 00:00:00 UTC). You are free to define other timestamps, but unix timestamp is well defined.
- mulmen 3y ago
  Seconds since epoch requires careful and precise handling of datatypes and assumptions. This works great inside a system where that can be managed but for the purpose of exchange between systems the ISO formats contain all relevant information. Either side can use a library to parse the string into their local representation. Comprehension by extraterrestrial life is a localization problem.
  - nerdponx 3y ago
    I'm not sure I understand. How is this different from any other quantity with an associated unit? What's the possible failure mode here, interpreting the "created_time_us" field as a distance in km instead of a timedelta in microseconds?
    - mulmen 3y ago
      Is the unit seconds or microseconds? How are leap seconds handled? What base type is used? Integer, number, or float? How many bits? What is the precision? What is the CPU architecture? Is it signed? How should overflows be handled? You can store weight as ohms of resistance on a load cell. But if you want to share that data you need to either normalize the number to a mutually understood unit or provide detailed information about your scale.
      - theK 3y ago
        > How are leap seconds handled? Unix time has uniform handling over leap seconds, regardless of the precision.
        mulmen 3y ago
        Yes that is true of Unix time. But is it true of every implementation? Are you sure? It might look like seconds since Uinx epoch but is it?
        theK 3y ago
- tsimionescu 3y ago
  This is the biggest general problem: you can't accurately compare the duration between two date times without having proper context of how the datetimes were stored or generated, especially for future dates. For example, you can't say today what the Unix timestamp will be for 1 January 2030, 10:00:00 AM in Bucharest, Romania. Romania may very possibly change timezone by then. So, if a user sets a meeting for that time, converting to the Unix timestamp according to the current timezone info is wrong. You'll end up alerting them on 1 January 2030 at 09:00:00 AM, or perhaps 08:59:58 AM if some leap seconds get added. Or it may even be entirely different if there is some calendar change for whatever reason by then. Note that UTC has a similar problem - which is why you actually need a local time string for this type of events.
  - theK 3y ago
    Correct, neither iso strings mor numbers can get you out of this dilema. While ISO uses UTC offset and time zone interchangeably it actually is only defined over offsets, not locations. I've had this problem discussed before. Typically the situation is firing events based on times at specific locations. It is neither straight forward with date libraries nor ist it easy with numeric computation. Sometimes it makes sense to render it down to a specific point in time at storage and not expect the country change timezone overnight. Some times the location itself may be changing randomly (moving objects) but in that case it typically just meant recalculating offsets on movement events.
- kortex 3y ago
  There's a lot more context baked into an ISO string than a unix timestamp though. Write a regex to find all the strict ISO8601-RFC3339 strings in a directory. Now write one for unix timestamps. > Also calculating amount of time between two ISO8601 strings without libraries is nor trivial, or any other operation actually. That's true of any datetime that actual humans use (as opposed to computers, financial systems, sysadmins and programmers).
  - theK 3y ago
    > Write a regex to find all the strict ISO8601-RFC3339 strings in a directory That is a weird edge case. I've had this before and the person proposing it hinged on some forensic practice which was based on analyzing human readable data. As I said in my original post, pretty printing ints to ISO timestamps is actually my original opinion.

yen223 3y ago

Crucially, that number could represent the number of seconds, or the number of milliseconds since Unix epoch (e.g. Date.getTime() in Java) You kinda have to guess from context that if it's a 10-digit number, it's probably seconds.

theK 3y ago
Fair point, types should be documented, but them again that's hardly a requirement nowadays, right?

bornfreddy 3y ago

I never understood this argument. The ISO8601 date string is as much a convention as a unix timestamp is - without context neither are decipherable. If anything, unix timestamp is easier to explain to an alien than a date string. It has a starting point (1970/01/01 00:00 UTC) and it counts seconds from then. Care to explain how an ISO8601 date string is constructed? Also calculating amount of time between two ISO8601 strings without libraries is nor trivial, or any other operation actually. When dealing with dates, there is only one simple way to work with non-localized times, and it's not ISO-something. EDIT: > ...and what epoch and timezone to use. This is also not correct. Unix timestamp has a well defined epoch and it doesn't deal with timezones (though the epoch itself is, of course, usually defined as 1970/01/01 00:00:00 UTC). You are free to define other timestamps, but unix timestamp is well defined.

mulmen 3y ago
Seconds since epoch requires careful and precise handling of datatypes and assumptions. This works great inside a system where that can be managed but for the purpose of exchange between systems the ISO formats contain all relevant information. Either side can use a library to parse the string into their local representation. Comprehension by extraterrestrial life is a localization problem.
- nerdponx 3y ago
  I'm not sure I understand. How is this different from any other quantity with an associated unit? What's the possible failure mode here, interpreting the "created_time_us" field as a distance in km instead of a timedelta in microseconds?
  - mulmen 3y ago
    Is the unit seconds or microseconds? How are leap seconds handled? What base type is used? Integer, number, or float? How many bits? What is the precision? What is the CPU architecture? Is it signed? How should overflows be handled? You can store weight as ohms of resistance on a load cell. But if you want to share that data you need to either normalize the number to a mutually understood unit or provide detailed information about your scale.
    - theK 3y ago
      > How are leap seconds handled? Unix time has uniform handling over leap seconds, regardless of the precision.
      - mulmen 3y ago
        Yes that is true of Unix time. But is it true of every implementation? Are you sure? It might look like seconds since Uinx epoch but is it?
        theK 3y ago
tsimionescu 3y ago
This is the biggest general problem: you can't accurately compare the duration between two date times without having proper context of how the datetimes were stored or generated, especially for future dates. For example, you can't say today what the Unix timestamp will be for 1 January 2030, 10:00:00 AM in Bucharest, Romania. Romania may very possibly change timezone by then. So, if a user sets a meeting for that time, converting to the Unix timestamp according to the current timezone info is wrong. You'll end up alerting them on 1 January 2030 at 09:00:00 AM, or perhaps 08:59:58 AM if some leap seconds get added. Or it may even be entirely different if there is some calendar change for whatever reason by then. Note that UTC has a similar problem - which is why you actually need a local time string for this type of events.
- theK 3y ago
  Correct, neither iso strings mor numbers can get you out of this dilema. While ISO uses UTC offset and time zone interchangeably it actually is only defined over offsets, not locations. I've had this problem discussed before. Typically the situation is firing events based on times at specific locations. It is neither straight forward with date libraries nor ist it easy with numeric computation. Sometimes it makes sense to render it down to a specific point in time at storage and not expect the country change timezone overnight. Some times the location itself may be changing randomly (moving objects) but in that case it typically just meant recalculating offsets on movement events.
kortex 3y ago
There's a lot more context baked into an ISO string than a unix timestamp though. Write a regex to find all the strict ISO8601-RFC3339 strings in a directory. Now write one for unix timestamps. > Also calculating amount of time between two ISO8601 strings without libraries is nor trivial, or any other operation actually. That's true of any datetime that actual humans use (as opposed to computers, financial systems, sysadmins and programmers).
- theK 3y ago
  > Write a regex to find all the strict ISO8601-RFC3339 strings in a directory That is a weird edge case. I've had this before and the person proposing it hinged on some forensic practice which was based on analyzing human readable data. As I said in my original post, pretty printing ints to ISO timestamps is actually my original opinion.