27 ms·

It is not computer-friendly because the timezone is unspecified. And in some timezones, it is ambiguous during changes from DST to winter time.

rocqua 1y ago
Looking through the original article, this date format is only available in the RFC, and then only with the Z (which makes it UTC). Is there a timezoned version of this that is standardized?
- dijit 1y ago
  the number after the Z is the offset to UTC. 2025-09-07 10:57:00Z+2 would be CEST for example. (+2 hours ahead). 2025-09-07 04:57:00Z-4 would be EDT (4 hours behind UTC)
  - isbvhodnvemrwvn 1y ago
    Offset is not the same as a timezone. Offsets change throughout the year in the same geographic areas (or don't or both do and don't)
    - dijit 1y ago
      No, timezones don’t change but they are swapped out by countries, offsets and timezones are an n:1 mapping. Multiple timezones represent the same offset, but those offsets are immutable. CEST will always be +2 UTC (unless something really changes politically). DST just marks that Sweden changes from CEST to CET from October to May. So Swedens offset changes, but the timezone does not change its offset.
      - KronisLV 1y ago
        At that point, just give me 2025-09-07T11:30:31.304[Europe/Riga] the machine can figure out the current offset and GMT itself because in any given time in the year I have no idea without looking it up.
      - School-Cotton 1y ago
        That’s wrong or at least not normally how the term “time zone” is used. We would typically say that Sweden is in one time zone whose offset changes twice a year.
        dijit 1y ago
        so CEST is what?
        School-Cotton 1y ago
        An offset from UTC. Wikipedia calls it "the standard clock time observed during the period of summer daylight-saving in those European countries which observe Central European Time (CET; UTC+01:00) during the other part of the year." Note the word "zone" does not appear in the above.
        yencabulator 1y ago
        Based on a quick skim, CEST is a "time" not a "time zone". https://en.wikipedia.org/wiki/Central_European_Summer_Time https://en.wikipedia.org/wiki/Central_European_Summer_Time https://en.wikipedia.org/wiki/Time_zone https://en.wikipedia.org/wiki/Time_zone https://en.wikipedia.org/wiki/Standard_time https://en.wikipedia.org/wiki/Standard_time
      - rocqua 1y ago
        There is the timezone "Amsterdam". That isn't a fixed offset.
aaronbrethorst 1y ago
Slap a Zulu on there for a little more safety and consistency. https://www.noaa.gov/jetstream/time https://www.noaa.gov/jetstream/time
mg 1y ago
Do you really need the timezone for each entry in the storage layer? The application knows how it stores data, so it can just use UTC or whatever it likes. One timezone for all entries. The interface then can display it in a way the user likes.
- nine_k 1y ago
  From bitter experience: yes, having TZ-aware dates and times everywhere is helpful, and saves you more in (lack of) trouble than it costs in storage and "hassle".
- NAR8789 1y ago
  This sounds like a footgun. At some point some application developer will introduce a bug where they're not sending utc. Without the time zone, the wrong times will end up in the database, bad data mixed in with good. This will be a nightmare to fix. With the time zone, I don't think this class of bugs is possible. Most application developers will wrap the time in an object that allows them to do time operations without needing to directly handle time zone in most cases.
- procaryote 1y ago
  Depends on what you need. If you specifically only care about moments in time, throwing away the input time zone might be fine. If the application is more human centric, timezones are often very useful as humans move around but often think about time as timezone-relative. A log of your daily activities would be confusing if a past event logged as 09:16:01 suddenly showed up as 07:16:01 because you're travelling when viewing it.
- isbvhodnvemrwvn 1y ago
  And then your country ditches/adopts the DST and you have angry customers because your app has messed up their future appointments.
- GoblinSlayer 1y ago
  You need time zone to parse time.
- 1y ago
fauigerzigerk 1y ago
Why is it not computer friendly? It's just a local time. This is something we need to be able to express in computers and in brains. Things like opening hours or appointment times are always local time, and even if Apple disagrees I very strongly believe that alarm clocks should use local time as well.
- pasc1878 1y ago
  Well is it a local time or not. If it is a local time where is it a local time? You need a timezone as well.
  - tsimionescu 1y ago
    A local time is not tied to a timezone. When I set my wake up alarm at 8:30 every day, it should stay at 8:30 regardless of the current timezone. If I travel to the USA, my phone shouldn't start waking me up at 22:30.
    - bsaul 1y ago
      The datetime mentionned in parent post had both a date and a time component, which has the meaning of a "point in time". Not just a "time". Point in time needs location information to guess the timezone, otherwise you simply can't make anything out of it. Your definition would have been just storing "hh:mm:ss".
      - ivan_gammel 1y ago
        You are right that LocalDateTime requires location, but it is not part of the data type and data format. It’s just date and time without timezone and location is stored separately.
        fauigerzigerk 1y ago
        >You are right that LocalDateTime requires location No. If I set a reminder for a particular date and time in the future, I want it to go off at that local date and time wherever I may be. The location cannot be part of the data type because "local" is sometimes relative to movable objects.
nine_k 1y ago
Fair. But the point is that it follows the only reasonable order, consistently from larger units to smaller. A datetime can be seen as a number written in a positional notation, just with varying base: divmod by 60, 60, 24, 12. When you pick a normal decimal / hex / binary number, you expect that the digits in it come in the order of magnitude changing: thousands, hundreds, tens, ones. Mixing them would feel crazy. By the same token, formats like dd-mm-yyyy HH:MM or mm-dd-yyyy are crazy; sadly they are traditional.
lmm 1y ago
Specifying an offset, as certain datetime formats do, is worse than not specifying any timezone information at all. I'm not aware of a standardised computer date format that includes the symbolic timezone, sadly.
- zarzavat 1y ago
  Agreed, offsets are an anti-pattern. Any time you have a nonzero offset you almost certainly want either a tz name (e.g. Europe/Paris), a local datetime, an instant, or a formatted string. Datetime + tz name: a point in time and space that is responsive to time zone changes. E.g. Our zoom meeting is on 3 Feb 2026 17:40 in Moscow time. Local date time: a calendar date that is independent of time zones. Instant: an exact point in time. e.g. the rocket will launch at 123456789 seconds from the Unix Epoch TAI. Formatted string: an exact point in time rendered for the human user in their local timezone and calendar, taking into account leap seconds. E.g. The rocket will launch on 7 Ramadan 1447 AH, Saudi time.
  - burntsushi 1y ago
    > Datetime + tz name: a point in time and space that is responsive to time zone changes No. It isn't a point in time, because time zone transition rules can and do change. You need an offset as well. Then you can choose which thing you want to prioritize[1] when converting it to an instant in time. This is what RFC 9557 is for. [1]: https://docs.rs/jiff/latest/jiff/tz/enum.OffsetConflict.html https://docs.rs/jiff/latest/jiff/tz/enum.OffsetConflict.html
    - lmm 1y ago
      What use case is there for preferring the offset (that wouldn't be better served by using instants)?
zarzavat 1y ago
Not all datetimes need a timezone. My next birthday is on November 17 2025 at 00:00 (it's not really). It's on that date regardless of where I am in the world, it follows me! So yes, I agree a local datetime format is necessary but not sufficient.

rocqua 1y ago

Looking through the original article, this date format is only available in the RFC, and then only with the Z (which makes it UTC). Is there a timezoned version of this that is standardized?

dijit 1y ago
the number after the Z is the offset to UTC. 2025-09-07 10:57:00Z+2 would be CEST for example. (+2 hours ahead). 2025-09-07 04:57:00Z-4 would be EDT (4 hours behind UTC)
- isbvhodnvemrwvn 1y ago
  Offset is not the same as a timezone. Offsets change throughout the year in the same geographic areas (or don't or both do and don't)
  - dijit 1y ago
    No, timezones don’t change but they are swapped out by countries, offsets and timezones are an n:1 mapping. Multiple timezones represent the same offset, but those offsets are immutable. CEST will always be +2 UTC (unless something really changes politically). DST just marks that Sweden changes from CEST to CET from October to May. So Swedens offset changes, but the timezone does not change its offset.
    - KronisLV 1y ago
      At that point, just give me 2025-09-07T11:30:31.304[Europe/Riga] the machine can figure out the current offset and GMT itself because in any given time in the year I have no idea without looking it up.
    - School-Cotton 1y ago
      That’s wrong or at least not normally how the term “time zone” is used. We would typically say that Sweden is in one time zone whose offset changes twice a year.
      - dijit 1y ago
        so CEST is what?
        School-Cotton 1y ago
        An offset from UTC. Wikipedia calls it "the standard clock time observed during the period of summer daylight-saving in those European countries which observe Central European Time (CET; UTC+01:00) during the other part of the year." Note the word "zone" does not appear in the above.
        yencabulator 1y ago
        Based on a quick skim, CEST is a "time" not a "time zone". https://en.wikipedia.org/wiki/Central_European_Summer_Time https://en.wikipedia.org/wiki/Central_European_Summer_Time https://en.wikipedia.org/wiki/Time_zone https://en.wikipedia.org/wiki/Time_zone https://en.wikipedia.org/wiki/Standard_time https://en.wikipedia.org/wiki/Standard_time
    - rocqua 1y ago
      There is the timezone "Amsterdam". That isn't a fixed offset.

aaronbrethorst 1y ago

Slap a Zulu on there for a little more safety and consistency. https://www.noaa.gov/jetstream/time https://www.noaa.gov/jetstream/time

mg 1y ago

Do you really need the timezone for each entry in the storage layer? The application knows how it stores data, so it can just use UTC or whatever it likes. One timezone for all entries. The interface then can display it in a way the user likes.

nine_k 1y ago
From bitter experience: yes, having TZ-aware dates and times everywhere is helpful, and saves you more in (lack of) trouble than it costs in storage and "hassle".
NAR8789 1y ago
This sounds like a footgun. At some point some application developer will introduce a bug where they're not sending utc. Without the time zone, the wrong times will end up in the database, bad data mixed in with good. This will be a nightmare to fix. With the time zone, I don't think this class of bugs is possible. Most application developers will wrap the time in an object that allows them to do time operations without needing to directly handle time zone in most cases.
procaryote 1y ago
Depends on what you need. If you specifically only care about moments in time, throwing away the input time zone might be fine. If the application is more human centric, timezones are often very useful as humans move around but often think about time as timezone-relative. A log of your daily activities would be confusing if a past event logged as 09:16:01 suddenly showed up as 07:16:01 because you're travelling when viewing it.
isbvhodnvemrwvn 1y ago
And then your country ditches/adopts the DST and you have angry customers because your app has messed up their future appointments.
GoblinSlayer 1y ago
You need time zone to parse time.
1y ago

fauigerzigerk 1y ago

Why is it not computer friendly? It's just a local time. This is something we need to be able to express in computers and in brains. Things like opening hours or appointment times are always local time, and even if Apple disagrees I very strongly believe that alarm clocks should use local time as well.

pasc1878 1y ago
Well is it a local time or not. If it is a local time where is it a local time? You need a timezone as well.
- tsimionescu 1y ago
  A local time is not tied to a timezone. When I set my wake up alarm at 8:30 every day, it should stay at 8:30 regardless of the current timezone. If I travel to the USA, my phone shouldn't start waking me up at 22:30.
  - bsaul 1y ago
    The datetime mentionned in parent post had both a date and a time component, which has the meaning of a "point in time". Not just a "time". Point in time needs location information to guess the timezone, otherwise you simply can't make anything out of it. Your definition would have been just storing "hh:mm:ss".
    - ivan_gammel 1y ago
      You are right that LocalDateTime requires location, but it is not part of the data type and data format. It’s just date and time without timezone and location is stored separately.
      - fauigerzigerk 1y ago
        >You are right that LocalDateTime requires location No. If I set a reminder for a particular date and time in the future, I want it to go off at that local date and time wherever I may be. The location cannot be part of the data type because "local" is sometimes relative to movable objects.

nine_k 1y ago

Fair. But the point is that it follows the only reasonable order, consistently from larger units to smaller. A datetime can be seen as a number written in a positional notation, just with varying base: divmod by 60, 60, 24, 12. When you pick a normal decimal / hex / binary number, you expect that the digits in it come in the order of magnitude changing: thousands, hundreds, tens, ones. Mixing them would feel crazy. By the same token, formats like dd-mm-yyyy HH:MM or mm-dd-yyyy are crazy; sadly they are traditional.

lmm 1y ago

Specifying an offset, as certain datetime formats do, is worse than not specifying any timezone information at all. I'm not aware of a standardised computer date format that includes the symbolic timezone, sadly.

zarzavat 1y ago
Agreed, offsets are an anti-pattern. Any time you have a nonzero offset you almost certainly want either a tz name (e.g. Europe/Paris), a local datetime, an instant, or a formatted string. Datetime + tz name: a point in time and space that is responsive to time zone changes. E.g. Our zoom meeting is on 3 Feb 2026 17:40 in Moscow time. Local date time: a calendar date that is independent of time zones. Instant: an exact point in time. e.g. the rocket will launch at 123456789 seconds from the Unix Epoch TAI. Formatted string: an exact point in time rendered for the human user in their local timezone and calendar, taking into account leap seconds. E.g. The rocket will launch on 7 Ramadan 1447 AH, Saudi time.
- burntsushi 1y ago
  > Datetime + tz name: a point in time and space that is responsive to time zone changes No. It isn't a point in time, because time zone transition rules can and do change. You need an offset as well. Then you can choose which thing you want to prioritize[1] when converting it to an instant in time. This is what RFC 9557 is for. [1]: https://docs.rs/jiff/latest/jiff/tz/enum.OffsetConflict.html https://docs.rs/jiff/latest/jiff/tz/enum.OffsetConflict.html
  - lmm 1y ago
    What use case is there for preferring the offset (that wouldn't be better served by using instants)?

zarzavat 1y ago

Not all datetimes need a timezone. My next birthday is on November 17 2025 at 00:00 (it's not really). It's on that date regardless of where I am in the world, it follows me! So yes, I agree a local datetime format is necessary but not sufficient.