[HN Gopher] RFC 3339 vs. ISO 8601
___________________________________________________________________
RFC 3339 vs. ISO 8601
Author : iamwil
Score : 220 points
Date : 2023-08-31 16:12 UTC (6 hours ago)
(HTM) web link (ijmacd.github.io)
(TXT) w3m dump (ijmacd.github.io)
| account-5 wrote:
| Damn, the timeout for redirecting me to GitHub was too short for
| me to allow JavaScript in uBlock!
|
| Anyway, can someone with more experience tell me when the huge
| ISO 8601 would be of use over RFC 3339?
|
| I can't imagine any application using 1% of the random formats
| available.
| mananaysiempre wrote:
| ISO 8601 also has notations for all sort of stuff the RFC
| doesn't need, like uncertain and approximate dates (for
| libraries or museums perhaps), as well as repeating events,
| durations, intervals, and such (some of that part is a riff on
| iCal, or so I've heard); most of it is in 8601-2 (which is a
| thing since the 2019 revision) but some parts are in -1.
| omoikane wrote:
| ISO 8601 supports all sorts of corner cases, apparently. But it
| costs money to get the full standard, unlike RFCs. Someone
| bought a copy and was answering questions few years ago:
|
| https://www.reddit.com/r/ISO8601/comments/mikuj1/i_bought_is...
|
| https://news.ycombinator.com/item?id=26672263
| account-5 wrote:
| I was unaware that it cost money. RFC for me (I say like I'd
| have a clue how to implement any RFC).
| asabil wrote:
| ISO8601 is a standard managed by ISO, you can buy a digital
| or printed copy of the standard from here:
| https://www.iso.org/standard/70907.html
|
| RFC 3339 is managed by the IETF, and their documents are
| accessible free of charge.
| mananaysiempre wrote:
| > you can buy a digital or printed copy of the standard
| from [the ISO]
|
| Or from your national member body, which for some
| standards and countries can be substantially cheaper.
| seabass-labrax wrote:
| In Britain, standards can _sometimes_ be obtained for
| free via your library subscription (which would be orders
| of magnitude cheaper than the standards are directly, due
| to government subsidies for libraries).
| Symbiote wrote:
| Representing ranges/intervals ("1st-5th of September 2023") and
| periods of time ("Four days and two hours")
|
| It can represent a month without a day ("April 2024"), and a
| year without a month ("2024").
|
| In some countries week numbers are used for various purposes
| ("School starts in week 33 of 2024", "Recycling will be
| collected in odd-numbered weeks.").
| jiehong wrote:
| Durations are pretty nice and seriously missing from the RFC.
| layer8 wrote:
| In the general case, durations can be non-intuitive or
| ambiguous when applied across DST changeovers or leap seconds,
| or when they include a month count.
| l0b0 wrote:
| I don't think anybody involved in date/time programming
| disagrees, but I'd rather have a single standard for both
| than having to use two standards.
| Karellen wrote:
| I find it weird that there's no way to specify a future date/time
| with respect to a specific timezone, e.g. Europe/London.
|
| I don't think it's unreasonable to want to be able to specify a
| meeting in London, on July 1st 2030, at 6pm local time - no
| matter what happens to UK timezones between now and then.
|
| The UK currently uses Z+00:00 from November to March, and
| daylight savings of Z+01:00 from April to October (roughly)[0].
| But it's possible that between now and 2030 they might adopt
| Central European (Summer) Time[1], or retry British Double Summer
| Time[2], or scrap daylight savings entirely. Therefore, what
| happens to 6pm with respect to any given epoch might vary wildly
| between now and 2030.
|
| But it would be nice to set a calendar event for "6pm London
| time", whatever London time happens to be when the event rolls
| around. But there's no standardised interoperable way to say
| "2030-07-01 18:00:00 Europe/London".
|
| [0] https://en.wikipedia.org/wiki/British_Summer_Time
|
| [1] https://en.wikipedia.org/wiki/Central_European_Time
|
| [2]
| https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of...
| slim wrote:
| Why do you think you can't do that ?
| tadfisher wrote:
| What if London doesn't exist by the event time?
| kzrdude wrote:
| I have never thought about it before, but are timezone names
| like 'Europe/London' designed to not be sensitive to
| political changes and not have to change?
|
| It could have been Country/City or Region/Country but it's
| Continent/City instead.
|
| Continents or regions of the world don't change fast or due
| to politics (not often) and cities aren't renamed or
| disappear that often, so this scheme is probably a lot more
| stable than any that uses political entities. (Think about
| countries that split or rename or become occupied, the
| locations of cities like Sevastopol (occupation), or Juba
| (Sudan/South Sudan split) or Jerusalem (every controversy).)
| fanf2 wrote:
| Yes, the city is chosen to be the most populous in the time
| zone. There's a long discussion of the policy in
| https://www.ietf.org/timezones/theory.html
| cesarb wrote:
| > What if London doesn't exist by the event time?
|
| Or what if it's split into two cities, which half were you
| talking about? This has famously happened with Berlin.
| klysm wrote:
| Then the scheduled time is probably irrelevant so who cares
| MichaelZuo wrote:
| Not necessarily the scheduled event may be in some other
| city in a different time zone that wants this timezone for
| the convenience of scheduling attendees from across the
| world.
| gumby wrote:
| In which case a new calendar appointment will be
| circulated to the survivors with location and details.
| This mechanism already exists and is surely adequate.
| MichaelZuo wrote:
| The point is to have some means, some facility, to
| schedule things 100% correctly in advance. If there
| literally is no possible method then that's a pretty
| surprising aspect of computer systems circa 2023.
| Mayelitol wrote:
| [flagged]
| rini17 wrote:
| You are either joking or you really think a RFC to cover such
| changes is possible? If so, do you have any examples in mind?
| Cities that stop existing is not a new problem.
| Karellen wrote:
| I'm content for that to be a failure mode of the format. :-)
| throw0101a wrote:
| > _What if London doesn 't exist by the event time?_
|
| Europe/London will be either be left alone for historical
| purposes, or aliased to its successor for backwards
| compatibility.
|
| See _Type: Link_ and _Source file: backward_ :
|
| *
| https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
| gumby wrote:
| Might be hard to meet there without radiation protection.
| the_duke wrote:
| I usually solve this by storing an explicit named timezone in
| an additional field.
| klysm wrote:
| Is LocalDate + LocalTime not sufficient? It seems like if you
| defer to computation of the instant that would be fine
| danbruc wrote:
| You want three pieces of information, a date, a location and a
| local time. Note that I do not think you actually want a time
| zone, what if you are not in London and that place gets moved
| into another timezone?
|
| All our common date time formats are intended to represent a
| specific point in time and this you just do not have in your
| case. But it is actually not too uncommon that date and time
| specifications have a non-trivial structure, think a meeting on
| every last Friday of the month or a monthly meeting series
| starting on January 31st or two days before the end of each
| quarter.
|
| I would guess trying to come up with a standard that covers all
| the things people could come up with, would become quite
| complex quickly. So if simple dates, times or instants are not
| good enough, you are probably on your own, make some structure
| with all the required things.
| deathanatos wrote:
| > _But it would be nice to set a calendar event for "6pm London
| time", whatever London time happens to be when the event rolls
| around. But there's no standardised interoperable way to say
| "2030-07-01 18:00:00 Europe/London"._
|
| The only gotcha about such a thing is that there are ambiguous
| or impossible timestamps: 2023-11-05 01:30:00 America/New_York
| -- that's one of two different times.
|
| For calendaring, it would make sense, since "same wall clock
| time regardless" is what most people want1; there might be some
| UI difficulty/challenges to handle the weird times, and maybe
| one might want to have a way to specify a disambiguation in the
| syntax.
|
| Thankfully for calendaring those are _usually_ in the middle of
| the night, but I 've literally seen this happen in my career.
|
| 1though once you invite the first person in a zone that doesn't
| do DST madness, note that this causes the calendar time to
| wobble on their calendars. Some of my international coworkers
| have to put up with this.
| WirelessGigabit wrote:
| If I want a meeting at 9AM MST (Mountain Standard Time, which
| Phoenix observes year-round) then, when CA is on PDT (Pacific
| Daylight savings Time), they have the meeting at 9AM local
| time.
|
| But when CA switches to PST (Pacific Standard Time) the
| meeting shifts to 8AM for the people in CA.
|
| But if the people in CA lead, and always want the meeting at
| 9AM local time, then the meeting for the people in Phoenix
| will move from 9AM to 10AM and back.
|
| Can't have it all.
| extraduder_ire wrote:
| This is why I prefer, and try to use, "<time> <fine-
| location> time". Like: "Friday 6:30PM Vancouver time" and a
| world-clock to keep track of when that is. The website
| time.is is very useful for this.
|
| This takes a bit more effort, but it is less ambiguous and
| saves you from having to deal with the insanity that is
| time. DST switching will still cause issues but, as long as
| you're not the one cursed to implement that software, it
| should be fine with advance warning.
| wahern wrote:
| In the OP's example, 2023-11-05 01:30:00 America/New_York,
| 1:30AM occurs _twice_ as at 2:00AM the clock rolls back to
| 1:00AM. Normally this is resolved by including a
| disambiguating timezone, EDT (first 1:30AM) or EST (second
| 1:30AM). But if there 's no timezone indication to
| accompany a geographical location, there's no way to
| disambiguate the time.
| jameshart wrote:
| Right, to pick an actual time stamp for a particular
| local time in a particular location, you need to first
| choose at what time stamp to resolve the time offset for
| the location. Then in that time offset you can
| unambiguously map the localtime to a unique time stamp.
| deathanatos wrote:
| If there's no flag indicating _DST_. America /New_York is
| the timezone designation.
|
| Part of what makes TZ discussions incredibly difficult is
| that people play fast and loose with the terminology.
|
| I think the person you're responding to is simply saying
| that if you made the meeting in a non-DST observing zone,
| the meeting time would still wobble in a DST-observing
| zone. (I'm not sure why they're noting it, because my
| comment also clearly spells that out, too, albeit in
| reverse. But yes, it works both ways.)
| deathanatos wrote:
| I'm well aware. See the footnote.
|
| I know it works both ways, too, but probably would be
| better for the DST observing zone to deal with the effects
| of DST, instead of foisting such side effects onto our
| international friends.
| [deleted]
| jiehong wrote:
| In the calendar world (iCal), this is actually supported: a
| date time without a time zone is a local time only [0].
|
| [0]: https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5
| Karellen wrote:
| But if I send that to someone who is in a different timezone,
| e.g. in America/New_York, will it put the event at 6pm
| _London Time_ in their calendar, so that they can videocall
| in at whatever time that is where they are?
| michaelt wrote:
| The ical format allows dates like _DTSTART;TZID=Europe
| /London:20230901T201000_
|
| Whether your calendar software will let you choose how it
| expresses the timezone and whether the recipient's calendar
| software will store it that way is another question...
| nightpool wrote:
| Google Calendar does, at least. It even supports
| representing events that being and end in different
| timezones (like a plane flight or a cross country trip)
| wrs wrote:
| Not quite -- that requires you to find the time zone locality
| out of band somehow. The request is to have a standard way to
| store the time zone (not the _current offset_ of the time
| zone) in the same string as the date /time.
| codetrotter wrote:
| Yup. Similarly with the time zone aware Rust crate "chrono"
| you also have datetime representations for local time called
| "naive" datetime to store date time without time zone.
|
| And likewise in PostgreSQL you can store timestamp without
| time zone.
|
| Combine that representation with lat/long gps coordinates and
| you have what you need for scheduling future events at
| specific locations regardless of changes in time zone names
| and offsets.
| fanf2 wrote:
| As well as what wrs said in a sibling comment, iCalendar does
| not have a way to specify the location of a meeting in a
| machine-readable way that can be turned into the timezone for
| that location.
|
| Sadly, iCalendar is very much tied to using timezones for
| locations. I expect that if/when Europe finally gets round to
| abolishing DST, there will be some significant changes to the
| timezone boundaries, and as a consequence, much hilarious
| calendaring failure. Dunno if it will affect as many people
| as the 2007 DST changes in North America, which caused a lot
| of extra work for people running Microsoft Exchange, because
| it was designed assuming that timezones never change. And
| this design error carries over to iCalendar, tho (apart from
| tz boundary changes) it is better than it was.
| jbandela1 wrote:
| I think you want it more specific than a timezone.
|
| For example, instead of London, suppose you wanted to meet in
| Glasgow, Scotland, on July 1st 2030, at 6pm local time.
|
| Currently, Glasgow in is timezone Europe/London.
|
| However, it is not unimaginable that in that time, Scotland
| could hold another referendum on independence and either join
| Central European Time, or create Scottish Standard Time.
| jvanderbot wrote:
| And so, you want a probabilistic time estimate based on the
| likelihood of that passing?
| toast0 wrote:
| I think it's reasonable to estimate the future time based
| on the current published rules. You don't need to guess at
| the probability of future published rules, but you do want
| to have sufficient information to reevaluate the published
| rules.
|
| This is why storing UTC dates for future events is
| insufficient: if the event is actually specified in local
| time, the date is incorrect when the time zone rules are
| changed. But storing the time zone is insufficient if the
| time zone that applies to the event also changes; you also
| need to store enough information to reevaluate which time
| zone is applicable.
|
| Of course, it can be difficult to gather this information
| in a user friendly way, so you know, compromises.
| codetrotter wrote:
| Store the gps coordinates of the location for the meeting
| instead, along with the desired local time and local date.
| isbvhodnvemrwvn wrote:
| This limits your meetings to surface of earth, what if I
| want to meet with you on Mars?
| jvanderbot wrote:
| But the local time would change according to GP's
| comment.
| codetrotter wrote:
| The top level comment said
|
| > specify a meeting in London, on July 1st 2030, at 6pm
| local time - no matter what happens to UK timezones
| between now and then
|
| GPS coordinates + local date and local time will preserve
| "a meeting in London, on July 1st 2030, at 6pm local
| time" in the desired way
| jvanderbot wrote:
| How: 6PM local time could mean Zulu+6 or Zulu+3 or
| anything else if local timezone offset changes via
| legislation. The best way to do it would be to say "X
| seconds from the time this message was sent"
| avianlyric wrote:
| > 6PM local time could mean Zulu+6 or Zulu+3 or anything
| else if local timezone offset changes via legislation.
|
| That's the point. Normal people think about time based on
| their local time. If they agree to meet someone at 3pm on
| a day in the future, that normally means turning up on
| that day when a local clock on that day reads 3pm. If
| local time changes offset from UTC, then the meeting
| implicitly also changes.
|
| I've personally yet to meet someone that reschedules all
| their appointments every time day light saving (or the
| inverse) rolls around. Just make sure their appointment
| times in UTC don't change.
| kelnos wrote:
| +6 or +3 is irrelevant to the scheduler when they're
| setting the meeting time: they want it to be 6pm
| regardless of any time zone changes in the future. So
| they deliberately do not store the UTC offset with that
| time. They only store the geographic location.
|
| Then when the meeting time is approaching, the software
| can figure out what time zone (and UTC offset) applies,
| after taking account any time zone changes that have
| taken place in the intervening years, and appropriately
| set reminder notifications.
|
| If they were to store "X seconds from the time this
| message was sent", then any time zone change would likely
| make it _not_ fall at 6pm on the target day, so that 's
| not what they'd want.
| noselasd wrote:
| "X seconds from the time this message was sent" would
| certainly not hit 6PM local time if the local timezone
| offset changed - unless you also update X every time it
| does.
| wrs wrote:
| The point is that the local time would _not_ change, even
| though the offset between UTC and local _did_ change.
| jvanderbot wrote:
| I see.
|
| The problem is there is no difference between local time
| and "offset from UTC", right?
| kelnos wrote:
| Local time has no notion of a UTC offset. Local time is
| just "9am on August 31, 2024". It's up to the
| application's implementation details to pair it with a
| physical location (e.g. some lat/long in London). The app
| would then have to (as the event date approaches) resolve
| that into something more computer-clock-understandable;
| that is, it would have to say "this lat/long is located
| in timezone XYZ, which has offset ### for that date", so
| it could tell the OS's notification service to pop up
| reminders at the appropriate times.
| codetrotter wrote:
| > there is no difference between local time and "offset
| from UTC"
|
| The difference is between applying the UTC offset for a
| future event using present rules. What we are saying is
| you should not do that because the rules can change.
|
| I ask you today that we meet at 3PM on January 24th in
| 2026, at the train station in Berlin.
|
| In my paper calendar book for I mark the date January
| 24th 2026 with the following note: "meet jvanderbot at
| 3PM at the train station in Berlin".
|
| I carry this book with me for the next few years.
|
| Meanwhile, you decide to be modern so you store a note
| about the meeting in a database. In doing so, you convert
| the information into a UTC offset for that future time.
| But you are using current rules for today, which may
| change.
|
| And then when the day arrives, there has been political
| changes in the meantime that made it so that the utc
| offset is different.
|
| Because you converted to utc offset ahead of time, your
| representation of the time no longer maps to "3 PM" but
| instead to let's say "4 PM".
|
| I show up at 3 PM local time, as we had agreed. But you
| are nowhere to be seen because in your digital calendar
| the meeting appears to be for "4 PM".
|
| This is what we mean when we are talking about the
| problem with converting a local time to a UTC offset a
| long time ahead.
| scbrg wrote:
| As long as the invited people don't change nationality...
|
| https://www.972mag.com/the-worlds-only-ethnic-time-zone/
|
| If there's one thing I've learned about time keeping,
| it's that whenever you think you've got it all figured
| out, there's always one more corner case.
| stouset wrote:
| That seems to be in line with what GP wants.
| jvanderbot wrote:
| I see. I misunderstood!
| layer8 wrote:
| The problem is that we don't know what the timezone
| identifiers for hypothetical future timezones will be.
| Meaning, there would be no automated way to associate those
| future-date-time values with the correct timezone once the
| new timezone is added to the tz database.
|
| One could imagine using geo coordinates or similar, but the
| mapping from those to timezones (or from/to zip codes or area
| codes) is already not precisely defined.
|
| If you use city names, those might also be split/merged
| (Berlin) or renamed (Constantinopel).
| naniwaduni wrote:
| What time zone people use at a given location is not even a
| function of geographical location; you plausibly also need
| to know language, culture, political affiliation, and/or
| employment status.
| chaz6 wrote:
| If you use coordinates, make sure to take into account
| continental drift. You could use a plate-local coordinate
| system (e.g. British National Grid for Great Britain) so
| you only need to take into account deformation.
|
| There is actually a good read on this at
| https://www.ordnancesurvey.co.uk/blog/is-britain-on-the-
| move
| crooked-v wrote:
| What about storing current geo coordinates and a
| timestamp of when they were recorded? I feel like that
| should be enough for a theoretical future system to
| adjust mapping for continental drift.
| joshspankit wrote:
| Especially assuming an increase in computing intelligence
| in that time.
| [deleted]
| mikequinlan wrote:
| >there would be no automated way to associate those future-
| date-time values with the correct timezone
|
| You could develop a way to specify a location and indicate
| that you mean 'local time' at that location.
| djbusby wrote:
| The zone database recently had a city spelling change on
| Kiev to Kyiv
| ilyt wrote:
| _change_ or adding same entry with the name of city
| changed ?
|
| Coz change like that could fuck some shit up...
| LegionMammal978 wrote:
| A link was added from "Europe/Kiev" to "Europe/Kyiv" in
| the included-by-default backward file [0], so that any
| user that doesn't exclude that file will simply treat the
| old name as an alias for the new name.
|
| [0] https://github.com/eggert/tz/commit/e13e9c531fc48a04f
| b8d064a...
| 1-more wrote:
| There are a few kinds of entry in the tz database.
| Europe/Kiev is now a Link entry to Europe/Kyiv which is a
| Canonical entry. Europe/Kiev used to be a canonical
| entry. What's interesting is there's a lot of thoughtful
| commentary about changing the name and handling the
| annexation of Crimea long before Russia invaded Ukraine
|
| For example: https://data.iana.org/time-
| zones/tzdb-2020d/europe (search for Kiev for the specific
| part; it's a very long file)
| ilyt wrote:
| 2030-07-01T18:00:00~Scotland/Glasgow ?
| lmm wrote:
| > However, it is not unimaginable that in that time, Scotland
| could hold another referendum on independence and either join
| Central European Time, or create Scottish Standard Time.
|
| Or be in the middle of a political dispute, with different
| times being used depending which side one is on, like
| Xinjiang. So just knowing the place and local time isn't
| enough.
| ydnaclementine wrote:
| Potential RFC idea?
| ainar-g wrote:
| There are a few ways to represent that in the database, see[1].
| Unless I misunderstood what you mean by "no way to specify".
|
| [1]: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-
| not-a...
| LegionMammal978 wrote:
| There's currently a draft document for such a format [0],
| called IXDTF (the Internet Extended Date/Time Format). It
| allows you to specify a timezone (as a tz name) in brackets
| following an RFC 3339 string. To give a local time, you have to
| specify your best estimate of the UTC offset alongside the
| bracketed timezone. For instance, "2030-07-01 18:00:00
| Europe/London" would be
| "2030-07-01T18:00:00+01:00[Europe/London]".
|
| If the UK changes its rules before that time, then the
| timestamp becomes "inconsistent" (see section 3.4). The
| behavior on an inconsistent timestamp is left for the
| application to decide, but if a ! character is included within
| the brackets before the timezone name, then it's at least
| obligated to detect the problem instead of blindly following
| the UTC offset:
|
| > In case of inconsistent time-offset and time zone suffix, if
| the critical flag is used on the time zone suffix, an
| application MUST act on the inconsistency. If the critical flag
| is not used, it MAY act on the inconsistency. Acting on the
| inconsistency may involve rejecting the timestamp, or resolving
| the inconsistency via additional information such as user input
| and/or programmed behavior.
|
| This extended timestamp format is used in the proposed Temporal
| library for JavaScript [1] (though I'm not sure if it supports
| the ! character). The ZonedDateTime.from() parsing function [2]
| takes an optional "offset" parameter to allow the user to
| control which part of an inconsistent timestamp takes
| precedence. It also supports simply omitting the UTC offset and
| using only the timezone, but it warns that this is ambiguous
| for times in the repeated hour during a DST transition.
|
| [0] https://www.ietf.org/archive/id/draft-ietf-sedate-
| datetime-e...
|
| [1] https://tc39.es/proposal-temporal/docs/strings.html#iana-
| tim...
|
| [2] https://tc39.es/proposal-
| temporal/docs/ambiguity.html#ambigu...
| djbusby wrote:
| Maybe
|
| ` 2030-07-01T18:00:00[!Local] `
|
| Where no offset and the !Local tell the app to use OOB
| defined location?
| ilyt wrote:
| maybe ~ ? 2030-07-01T18:00:00~BTC
| 2030-07-01T18:00:00~CEST
| 2030-07-01T18:00:00~Local
| 2030-07-01T18:00:00~Europe/Warsaw
|
| to signify it is not a constant point in time but timezone-
| at-the-time dependent.
| mjevans wrote:
| The issue is, what do you mean?
|
| This time description in the indicated timezone, at the
| instant it is correct? (Ignore updates, I mean the time I
| said. E.G. The doors open at 8am every day.)
|
| An indicated end of a duration, such as the period of
| time a mass of decaying radio-isotopes are valid for the
| sensor during? (Offhand, no consumer equipment comes to
| mind, but for an extremely sensitive calibrated sample it
| could matter and this is a contrived example.) Exact
| moment in monotonic time. (What about stretchy leap
| seconds too?)
|
| Something between the two extremes?
|
| Most humans probably want a default of something like...
|
| "Looser more common use time unless I get more specific."
| So if a TZ is included, it isn't a fixed moment, but
| whatever specifier is the valid moment as that moment
| passes. Convert it to an absolute monotonic value at that
| time to record the event and not just the specification
| of when to capture the event's passing.
|
| E.G. Unix time Epoch was 1970-01-01 00:00:00~Z with an
| absolute reference value of 0s DATE RoundedHour~US.EST =>
| Actually is EDT but most people don't use that notation,
| and congress changed when DST happens yet again without
| abolishing it too, and this happened last year before the
| change but the event did run from Noon to 9PM with these
| event moment second values...
| seabass-labrax wrote:
| That's an excellent idea, and one which I should hope to
| implement in my calendaring software if it is accepted. Are
| you one of the authors?
| LegionMammal978 wrote:
| No, I'm not affiliated with the authors, I just recalled
| seeing the extended syntax when I looked into Temporal's
| features a while back.
| ivan_gammel wrote:
| It's LocalDateTime AND geographic coordinates, not a name of a
| timezone. Maybe we need an ISO standard for universally
| accepted location/event identifiers or an URI schema, eg:
| event://de/Berlin/10557/Platz+der+Republic,+1/Bundestag#2030-08
| -30T18:00
| jameshart wrote:
| Yes the basic problem here is that people for some reason
| think that a time zone is a property of a _time_ when in fact
| a time zone is a property of a _place_. It's actually a
| _mutable_ property of a place, to make things more complex.
| lmm wrote:
| Places do not necessarily have a single agreed timezone -
| see Xinjiang (or indeed Crimea).
| codetrotter wrote:
| Country borders can change, city divisions can change. Street
| names can change, and streets can disappear.
|
| Use GPS coordinates instead :D
| lxgr wrote:
| Nice idea in theory, but then you need to accommodate for
| continental drift as well :)
| ivan_gammel wrote:
| I was expecting that comment and this would be my
| preferred answer.
| ivan_gammel wrote:
| Not instead, but in addition to. Maybe 3rd element of the
| vector must be the moment when the identifier was created,
| so that knowing history of the location it could be
| possible to adjust it to the current coordinates.
| rini17 wrote:
| That won't help if the Bundestag moves into another
| building. If country borders change, that is also likely to
| occur :D
| tonyhb wrote:
| This is supported in Google Calendar. You set the TZ when
| you're creating an invite.
| crooked-v wrote:
| Of course, then you get into the problem of whether you want to
| store that by time zone, or by actual physical location. If
| it's the latter, you might have to deal with the time zone that
| covers that location changing at some point between now and
| then, like when Kazakhstan merged what were previously two
| separate time zones into one.
| CodesInChaos wrote:
| One complication with that format is that local time can be
| ambiguous or not exist at all, if the time is during DST
| switching.
| codetrotter wrote:
| Add one extra bit to store "disambiguation".
|
| Value 0 meaning "if there is a DST switch, interpret the time
| as the chronologically earlier one"
|
| Value 1 meaning "if there is a DST switch, interpret the time
| as the chronologically later one".
| CodesInChaos wrote:
| Yes, a suffix like `S`/`W` (for Summer/Winter) or `+`/`-`
| in place of Z would help with disambiguation.
|
| But you still need to handle the case where the local time
| is skipped. You could pick the timestamp during which the
| skip happens, but that'd lead to an offset that can contain
| fractional seconds, which almost no datetime library
| supports.
| proto_lambda wrote:
| That works until a country decides to hop across the
| international date line the day after they switch from DST
| to normal time, and the timestamp occurs three times ;)
| mike_hock wrote:
| > But it's possible that between now and 2030 they might adopt
| Central European (Summer) Time[1], or retry British Double
| Summer Time[2], or scrap daylight savings entirely.
|
| Yes, and maybe East London secedes from the UK and uses a
| different time zone, so Europe/London doesn't specify the time
| zone you meant, anymore. This might not be likely for London,
| but if it's in the countryside of a less stable country and you
| just specified the time zone as the capital city, this might
| happen.
|
| I prefer time formats that are actually implementable and don't
| depend on a large database that can change at any moment.
| koliber wrote:
| The current time formats depend on databases that can change
| at any time. I haven't found one that is implementable and
| usable in the real world that does not depend on something
| that can be changed.
|
| Countries change. Timezones change by decree. This is a pain
| but it's the real world and our tools need to be able to deal
| with it. I don't like it either, and no one cares, nor should
| they. Reality trumps preference.
| crote wrote:
| The problem with ISO 8601 is that it _isn 't_ properly
| implementable. Anything except Zulu time is basically broken.
|
| The tz database is updated on average every two months, and
| that doesn't happen without reason. Countries keep changing
| their timezones, and a rather high-profile one is the
| European Union's plan to get rid of DST over the next few
| years. This is already happening in Greenland _this year_.
| Some Muslim-majority countries also like to make their DST
| depend on Ramadan - which falls on a different and somewhat
| unpredictable date every year.
|
| Like it or not, if your code uses future dates and does not
| rely on "Europe/London"-style timezones, you _will_ be slowly
| corrupting your data.
| mike_hock wrote:
| > Anything except Zulu time is basically broken.
|
| How so? 2030-07-01T18:00:00+01:00 is a well-defined point
| in time, is it not? It may or may not be local time in
| London, but it's unambiguous.
|
| July 1st 2030, at 6pm, Europe/London is not. What's broken
| is the idea that you can somehow standardize "local time at
| a particular place" in a way that magically survives any
| arbitrary policy change.
|
| > Some Muslim-majority countries also like to make their
| DST depend on Ramadan - which falls on a different and
| somewhat unpredictable date every year.
|
| Thus proving that what you want does not exist and cannot
| exist.
| lmm wrote:
| > How so? 2030-07-01T18:00:00+01:00 is a well-defined
| point in time, is it not? It may or may not be local time
| in London, but it's unambiguous.
|
| It's a redundant way of writing 2030-07-01T17:00:00Z
| which only serves to cause confusion (it misleadingly
| looks like a local time, but it isn't). TAI or equivalent
| are useful; symbolic timezones are useful; numeric time
| offsets are useless and there's no benefit from having
| them be part of the standard.
|
| > Thus proving that what you want does not exist and
| cannot exist.
|
| Of course it does; 2030-07-01T18:00 Africa/Casablanca is
| a real time that humans will have no trouble attending a
| meeting at, and nor will computers as long as they've
| been keeping their zone file up to date. All we need is a
| standard for storing and interchanging it on computers.
| tux1968 wrote:
| > How so? 2030-07-01T18:00:00+01:00 is a well-defined
| point in time, is it not? It may or may not be local time
| in London, but it's unambiguous.
|
| Being unambiguous isn't helpful if it is wrong. It is a
| very common desire to want to set a meeting based on the
| local time of a destination. The only future-proof way to
| store such a time, is to remember the destination and the
| desired local time. This is the only way the proper
| moment can be calculated and kept in sync with reality.
|
| The unfortunate fact is, the local time could be altered
| by decree, in any number of ways, in the interim timespan
| between setting a reminder, and when it happens.
| jameshart wrote:
| In general one problem with that request is that it's possible
| to specify times that might not actually happen.
|
| 2030-03-24 01:30:00 Europe/London seems like a perfectly
| reasonable time stamp. But if the UK decides to move BST
| forwards by a week between now and 2030, that time won't ever
| happen.
| gorgoiler wrote:
| 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 wrote:
| 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 wrote:
| the standard could simply allow county/city specifiers. or
| GPS coordinates.
| deathanatos wrote:
| 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 wrote:
| ... 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 wrote:
| 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 wrote:
| 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.
| gorgoiler wrote:
| 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
|
| 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.
| cratermoon wrote:
| Notice there is no format in which timezone is specified as 4
| digits without the colon, and yet 'date +%z' returns +-NNNN.
| aendruk wrote:
| Thankfully we have %:z. Relatedly, it's possible to teach date
| to do this by default:
| https://gist.github.com/d081dad407432d53172e30d0d35c39db
| $ date 2023-08-31T11:15:00-07:00
| cratermoon wrote:
| +%:z is a gnu-specific extension, though. The gist you linked
| works with gnu libc, but I'm not aware of a POSIX-compliant
| way to do it.
| CodesInChaos wrote:
| One part of RFC 3339 I dislike is `Z` vs `+00:00` vs `-00:00`
|
| > Unknown Local Offset Convention
|
| > If the time in UTC is known, but the offset to local time is
| unknown, this can be represented with an offset of "-00:00".
|
| > This differs semantically from an offset of "Z" or "+00:00",
| which imply that UTC is the preferred reference point for the
| specified time.
|
| `Z` should have been used to represent the unknown local time
| case, and `-00:00` shouldn't exist, while `+00:00` could be used
| if UTC is the preferred reference point.
|
| In practice `Z` is already used for the "no preferred local time"
| case very often.
| taftster wrote:
| Fixed this for you: In practice `Z` is
| already used *wrongly* for the "no preferred local time"
| burkaman wrote:
| Wow that is very surprising, I always thought -00:00 was just a
| synonym for +00:00. That seems almost intentionally misleading,
| why not Z like you say or just +? or something?
| [deleted]
| foresto wrote:
| Reminds me of the +1 / -1 / +0 / -0 convention that was once
| common in open source development discussions. For example:
|
| https://community.apache.org/committers/consensusBuilding.ht.
| ..
|
| I wonder if that convention had something to do with this
| choice of syntax.
| mankyd wrote:
| Thank you for this comment. I saw the `-00:00` in the RFC 3339
| bubble, and was confused as to why it wasn't mutually agreed
| upon. Your comment makes clear the the `-` has special meaning
| that I hadn't picked up on.
| toast0 wrote:
| I thought Z was a reference to (NATO) Military time zones [1],
| where Zulu Time Zone is equivalent to UTC+00:00, but uses fewer
| characters.
|
| iCal uses the Z to indicate times intentionally in UTC as well,
| as opposed to times without a time zone indicator (use unknown
| local time), or times with an explicity time zone indicator.
|
| Using Z to indicate 'please use whatever local time seems
| appropriate' seems like poor practice, even if it's a common
| one.
|
| [1] https://en.wikipedia.org/wiki/Military_time_zone
| CodesInChaos wrote:
| In my experience "this timestamp is UTC, show it to the user
| in whatever timezone they might be in" is the most common
| case for times in an API/file format, so giving it the Z
| shorthand makes sense to me.
|
| While when using an explicit time offset, `+00:00` doesn't
| appear particularly special or more common than other
| offsets, so I don't think a shorthand for this case is
| useful.
| ledauphin wrote:
| the tables agree that microseconds are supported by both
| standards, but for some reason the Venn Diagram only displays
| 6-digit fractional seconds under ISO8601. This led me to do some
| head-scratching until I referenced the table, which seems a lot
| more comprehensive.
|
| This is extremely cool and useful overall, but unfortunately the
| Venn Diagram seems to be slightly misleading.
| jmull wrote:
| What a great visualization for this.
|
| I'd prefer to use space (or underscore) instead of T to separate
| the date and time parts, but generally stick with T to avoid
| problems with anything that can only handle ISO 8601 (and to be
| consistent).
| cryptonector wrote:
| I prefer T because nothing will be splitting these strings on T
| by accident.
| Alupis wrote:
| Two questions:
|
| 1) What is the reasoning behind 6 digit years? Surely any system
| contrived today will not exist in the year 100,000.
|
| 2) ISO 8601 is prolific. Is RFC 3339 well used/adopted in any
| system?
| noselasd wrote:
| > 1) What is the reasoning behind 6 digit years? Surely any
| system contrived today will not exist in the year 100,000.
|
| But ... I want someone to put together a simulator that can
| estimate where Voyager 2 will be at e.g. 020000-01-01
| starlevel003 wrote:
| > ISO 8601 is prolific. Is RFC 3339 well used/adopted in any
| system?
|
| 90% of the time when a library says ISO 8601 it doesn't
| actually implement the more esoteric parts of ISO 8601.
| PhilipRoman wrote:
| Judging by the time it takes to completely migrate away from
| old technologies, I wouldn't be surprised if we will be
| emulating x86 on our quantum computers in the year 100k.
| throw0101a wrote:
| > _2) ISO 8601 is prolific. Is RFC 3339 well used /adopted in
| any system?_
|
| ISO 8601 was first published in 1988. RFC 3339, while
| ostensibly dated July 2002, codifies practices that date back
| to Usenet and e-mail (RFC 822: August 1982), and perhaps to the
| _date_ utility (which existed in Version 1 AT &T UNIX).
| pdw wrote:
| Nah, email and classic Unix use entirely unrelated date
| formats. The RFC 822 format looks like "Thu, 31 Aug 2023
| 20:53:11". Unix / ctime(3) uses "Thu Aug 31 20:56:52 2023".
| robobro wrote:
| RFC 822 is what RSS feeds use and RFC 3339 is what Atom
| feeds use.
|
| I don't know about you, but I think RFC 3339 dates are much
| more appealing :)
| rowanseymour wrote:
| I could imagine scientific tooling wanting to represent dates
| in the far future.
| paulddraper wrote:
| Y10k (:
| dabluck wrote:
| man the year 10,000 is really going to break a lot of software
| systems that assume a 4 digit year
| chungy wrote:
| Possibly; this assumes that our current calendar's epoch
| holds, that humanity is still around, that computing systems
| are still around, and legacy software from 8,000 years past
| is still kicking people in the butt.
|
| Given that electronic computing has only existed since
| approximately the 1930s, it's probably premature to worry
| about what will happen 8,000 years from now.
| airstrike wrote:
| Worse case scenario we can get around to updating stuff by
| the time we hit the year 9,900 or so
| Macha wrote:
| The ISO8601 standard is behind a paywall, and consequently many
| of the "ISO8601" functions in programming languages and
| libraries don't actually support anything but the subset that
| is also RFC 3339.
| rendaw wrote:
| Both Golang (official time package) and Rust (Chrono) have
| built in tools for dealing with RFC 3339 but not for RFC 8601.
| IIRC I read about issues with ambiguity in RFC 8601 not present
| in RFC 3339, and again IIRC Python had issues round-tripping
| dates because of this.
| Alupis wrote:
| Interesting. This is the first time I'm even hearing of RFC
| 3339. ISO 8601 is just taken for granted everywhere...
| languages, tools and services (databases, etc).
|
| Admittedly I've not worked with Golang or Rust, and my Python
| has been limited to scripting more than developing.
| pdw wrote:
| Almost everything that claims to implement ISO 8601
| actually implements RFC 3339 instead.
| rowanseymour wrote:
| I think a lot of people assume ISO 8601 just means
| 2023-08-31 / 2023-08-31T14:55:30Z.. if only
| cryptonector wrote:
| It's ISO 8601, not RFC 8601 (which is `Message Header Field
| for Indicating Message Authentication Status`).
| mitthrowaway2 wrote:
| Perhaps 6 digit years are intended to be useful for
| representing prehistoric dates?
| MattSteelblade wrote:
| It bothers me on a regular basis that there is no RFC 3339
| acceptable way to include date and time in a file name in Windows
| as a colon is a special character. I also wish you could use
| hyphens in the date while ignoring the colons and still be ISO
| 8601 compliant, for example 20230831T1510-0500 is compliant and
| can be used in a filename, while 2023-08-31T1510-0500 (and
| similar variants) is not. As an aside the "Get-Date" function in
| PowerShell doesn't understand the first timestamp without the
| hyphens and colon.
| cryptonector wrote:
| Removing the colons is perfectly safe and will not render
| RFC3339 dates and date-times ambiguous, and you can always
| losslessly restore those colons.
| tengwar2 wrote:
| I hadn't realised that there was a problem with Windows. MacOS
| has a different problem with a colon in a file name. For two of
| the three most popular operating systems to have this problem
| does show a distinct lack of thought.
| coding123 wrote:
| Time and money - the two things we literally can't solve even
| with AI.
| kuon wrote:
| Most of the time RFC is the way to go as ISO specs are not
| available for free and many open source implementation are
| actually not fully open source compliant because based on drafts.
| It's also a really big effort for open source devs.
|
| Also, if you are working on anything dealing with date in the
| future, you nearly always want to store wall clock time +
| location. Sadly, there is no standard for that.
|
| In Europe and USA the timezones are quite stable, so we might not
| be confronted to this, but in many places timzones change quite
| often, and storing an offset is not stable. Having "june 5 2026,
| 13h30 wall clock, paris" is what most people will mean, and it
| might be UTC+2 or UTC+1 depending if EU finally decide on what to
| do with DST.
|
| And finally, if you write an API with times in the past, just use
| POSIX timestamps in seconds, ms, us or ns.
| toast0 wrote:
| > Also, if you are working on anything dealing with date in the
| future, you nearly always want to store wall clock time +
| location. Sadly, there is no standard for that.
|
| iCalendar is _an_ RFC standard for this. [1] Note that some
| times have two representations and some times are not
| representable in this format when there 's a time change due to
| DST.
|
| iCal also does not contemplate a location being reassigned to a
| different time zone, an issue discussed elsewhere in this
| thread.
|
| Of course, properly formatted iCal files also include data for
| all of the referenced timezones. Which makes it cumbersome if
| you just wanted to output a single datetime.
|
| [1] https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-
| time.htm...
| Symbiote wrote:
| 2023-08-31/28
|
| I don't think that's valid, as the abbreviated form allows
| excluding identical parts, so expanded this is
| 2023-08-31/2023-08-28
|
| which has the start time after the end.
| devmunchies wrote:
| An often ignored part of the standards are how to represent
| durations (time spans).
|
| See http://xml.coverpages.org/ISO-FDIS-8601.pdf (section: 5.5.4.2
| Representation of time-interval by duration only, pg. 21)
|
| Would like to see more json parsers in static languages allow me
| to define a field as a time span and can serialize into the valid
| format.
|
| For an example, see this proposal in Crystal:
| https://github.com/crystal-lang/crystal/issues/11942
| Example: A duration of 15 days, 5 hours, and 20 seconds would
| be: P15DT5H0M20S A duration of 7
| weeks would be: P7W
| duped wrote:
| Why do you want a string format for data that can be
| structured? "duration": { "days":
| 15, "hours": 5, "seconds": 20 }
|
| Now it's not the job of your JSON parser to understand the
| semantics of your data. It's your input validator's - which is
| how it should be, imo.
|
| Note you will have to have some fallible conversion step from
| whatever JSON chooses to represent that data as anyway.
| atoav wrote:
| Because there can be benefits to having it compact and yet
| human readable? 2023-08-24T20:30:00Z
|
| versus "time" : { "year" :
| 2023, "month" : 8, "day" : 24,
| "hour" : 20, "minute" : 30, "second"
| : 0, "timezone" : "UTC", }
|
| Call me lazy, but tryping the latter took me 20 times longer.
| I totally would use it for internal state, but I would not
| store it like that or expose that to users ever.
| duped wrote:
| But you're talking about JSON, not a concise string that is
| exposed to users, and not a data format optimized for size.
| If you want more than a basic type you give it structure -
| and durations are not trivial types nor common enough to
| deserve their own representation.
|
| Durations optimized for storage without ambiguity would be
| the tuple (u64, u32, u8) where the first value is seconds,
| second value is nanoseconds (if precision is needed) and
| final value is epoch.
|
| Durations displayed to a user wouldn't ever be stored so
| the point is kind of moot.
|
| Optimizing for "time it takes someone to write it once" is
| kind of dumb since it happens once while reading it happens
| often, and parsing even more likely.
| NikkiA wrote:
| 6 digit years seem like a solution to a problem that will never
| be for the sake of looking forward thinking. There's absolutely
| no way current technology or social norms will last 8000 years.
| sedatk wrote:
| It just makes great easter eggs.
|
| "Hey, this guy had set his reminder to today. I wonder what
| he'd think if he knew we actually saw this 56,000 years later"
|
| "Well, let's regenerate him and ask"
| atoav wrote:
| Yeah, but don't forget we use computers for things that don't
| involve today only.
|
| Let's say you run a climate calculation for long enough for
| example. Now you could just say "fuck dates" if they error --
| but wouldn't it be kinda nice if they didn't?
___________________________________________________________________
(page generated 2023-08-31 23:00 UTC)