4 ms·

Having the tzdata zone at the end, after a space, makes perfect sense. I think you just invented the new standard? A wall clock / human readable time without

Having the tzdata zone at the end, after a space, makes perfect sense. I think you just invented the new standard? A wall clock / human readable time without a TZ is like a… …a horse without a field? …a burger without knowing the meat? …a photograph of a star without a position? …a lover without a name? Ok maybe too far. …a bonus without knowing the currency?

jvanderbot 3y ago
It's in ISO 8601. See the "Z"? that means "Zulu" or "+0". You can specify any offset. This is standardized and immutable. What offset is correct, however, can change due to local madness, and no standard could possibly keep up. But I do love the `date` utility, which allows alphanumeric time zone abbreviations pretty well.
- pas 3y ago
  the standard could simply allow county/city specifiers. or GPS coordinates.
- gorgoiler 3y ago
  The meaning of a wall clock time is based on the legal jurisdiction of where the clock is located. It is the local law which sets the daylight savings time rules. These are commonly written as TZ / tzdata / IANA names, as in “Europe/London” from the person to whom I replied. https://en.m.wikipedia.org/wiki/Tz_database https://en.m.wikipedia.org/wiki/Tz_database Even this is not enough for some edge cases like “I shall take my supper every day at 6pm, Jeeves” but one can always find exceptions to anything.
- deathanatos 3y ago
  It's not in ISO-8601. The suggestion above is to have the zone in the timestamp. ISO-8601 and RFC-3339 put the offset in the timestamp. Zone and offset are different concepts: the up-thread comment's poster's example of Europe/London is one zone, that currently has two offsets, depending on time of year. The up-thread comment includes a very practical example that any app dealing with something like an "appointment" would have to reckon with.
- crote 3y ago
  ... which means ISO 8601 cannot deal with timezones but only UTC offsets - which are temptingly useful but fundamentally broken. Including fixed UTC offsets was a massive mistake and it should have never happened. Anything except named timezones is useless.
  - lxgr 3y ago
    I personally find UTC offsets pretty useful for (free-form) meeting scheduling, i.e. "see you at 15:00 (UTC+2)" beats "see you at 15:00 (CET)". It makes quick mental math to figure out what that is in my current timezone so much easier. Otherwise, I'm also always left wondering whether they really meant CET or actually CEST, calculating what the current offset of CET is, double-checking whether there's some other CET that I might be confusing things with (China Eastern Standard Time?) etc.
  - michael1999 3y ago
    Offsets are just fine for timestamps, and other historical data. And much simpler than having to maintain history of TZ data, and trusting that all your collaborators are using the same TZ db. It is only scheduling future events where they fall down. Calendars and scheduling are demanding applications.

jvanderbot 3y ago

It's in ISO 8601. See the "Z"? that means "Zulu" or "+0". You can specify any offset. This is standardized and immutable. What offset is correct, however, can change due to local madness, and no standard could possibly keep up. But I do love the `date` utility, which allows alphanumeric time zone abbreviations pretty well.

pas 3y ago
the standard could simply allow county/city specifiers. or GPS coordinates.
gorgoiler 3y ago
The meaning of a wall clock time is based on the legal jurisdiction of where the clock is located. It is the local law which sets the daylight savings time rules. These are commonly written as TZ / tzdata / IANA names, as in “Europe/London” from the person to whom I replied. https://en.m.wikipedia.org/wiki/Tz_database https://en.m.wikipedia.org/wiki/Tz_database Even this is not enough for some edge cases like “I shall take my supper every day at 6pm, Jeeves” but one can always find exceptions to anything.
deathanatos 3y ago
It's not in ISO-8601. The suggestion above is to have the zone in the timestamp. ISO-8601 and RFC-3339 put the offset in the timestamp. Zone and offset are different concepts: the up-thread comment's poster's example of Europe/London is one zone, that currently has two offsets, depending on time of year. The up-thread comment includes a very practical example that any app dealing with something like an "appointment" would have to reckon with.
crote 3y ago
... which means ISO 8601 cannot deal with timezones but only UTC offsets - which are temptingly useful but fundamentally broken. Including fixed UTC offsets was a massive mistake and it should have never happened. Anything except named timezones is useless.
- lxgr 3y ago
  I personally find UTC offsets pretty useful for (free-form) meeting scheduling, i.e. "see you at 15:00 (UTC+2)" beats "see you at 15:00 (CET)". It makes quick mental math to figure out what that is in my current timezone so much easier. Otherwise, I'm also always left wondering whether they really meant CET or actually CEST, calculating what the current offset of CET is, double-checking whether there's some other CET that I might be confusing things with (China Eastern Standard Time?) etc.
- michael1999 3y ago
  Offsets are just fine for timestamps, and other historical data. And much simpler than having to maintain history of TZ data, and trusting that all your collaborators are using the same TZ db. It is only scheduling future events where they fall down. Calendars and scheduling are demanding applications.