[HN Gopher] RFC 3339 vs. ISO 8601
___________________________________________________________________
RFC 3339 vs. ISO 8601
Author : rdpintqogeogsaa
Score : 417 points
Date : 2021-10-24 10:19 UTC (12 hours ago)
(HTM) web link (ijmacd.github.io)
(TXT) w3m dump (ijmacd.github.io)
| Waterluvian wrote:
| Does anyone know of a website that lets you paste in date strings
| and it will show you all the possible formats they adhere to
| along with their format strings?
|
| I often come across a string and don't recognize the format and
| would love to just supply a bunch of examples and make a best
| guess.
| samhw wrote:
| This site is notionally devoted to Unix timestamps, but it
| covers a few popular formats: https://www.unixtimestamp.com/
| NelsonMinar wrote:
| Note that Python still lacks any way to parse these dates in the
| standard library. You have to use a third party library to parse
| them. You might think `datetime.fromisoformat` parsed ISO dates
| but you'd be wrong; it doesn't support the trailing Z or any
| other form of timezone information. The docs are clear about
| this, and the developer discussion I've read basically boils down
| to "it's too hard to parse ISO dates so we didn't do it here."
| This discussion has been going on for years.
|
| https://stackoverflow.com/questions/127803/how-do-i-parse-an...
| macintux wrote:
| Plus the naive date times that seem to pop up by default.
| Frustrating.
| Dunedan wrote:
| Can you elaborate on this?
|
| Parsing ISO 8601 formatted dates doesn't result in naive
| Python datetimes: >>>
| datetime.fromisoformat("2021-10-24T20:17:41+02:00")
| datetime.datetime(2021, 10, 24, 20, 17, 41,
| tzinfo=datetime.timezone(datetime.timedelta(seconds=7200)))
| NelsonMinar wrote:
| Your example demonstrates I'm wrong with isoformat not
| supporting _any_ timezone info. Sorry about that. Given it
| can handle +02:00 I wonder why they don 't just add support
| for z and Z and instantly cover 95% of the world's JSON
| data?
| willis936 wrote:
| Is the timezone necessary to be compliant? My favorite ISO 8601
| format is "%Y%M%DT%h%m%s%", but the table includes a "-Z" on the
| end and the "Now" column evaluates this as my current timezone.
|
| It says the list isn't exhaustive, but I'm just curious how often
| others actually embed the timezone rather than just passing
| around UTC.
| gerikson wrote:
| It's only needed for disambiguation.
|
| That said, I wish the page had actually taken the local time
| into account. As in your case the times on the page are in my
| current timezone (CEST) so the "Z", "00:00", "+00:00" is
| basically just decoration.
|
| ~~Even worse, in the intersection we have formats like
| %h:%m:%s+Z and %h:%m:%s+02:00 that show the same time
| simultaneously.~~
|
| Edit: it is correct now.
| drdec wrote:
| I'm in the America/New_York zone and I see the proper times
| for the values with "Z" vs the values with "-4:00". That is,
| they are off by four hours.
| lborsato wrote:
| I'm in America/New_York as well and I see them correctly. I
| think your computer's time zone may be incorrect.
| [deleted]
| Macha wrote:
| If you're looking in the backwards direction and its important
| what local time in a different location it happened, that's the
| use case for offset date time. Maybe you're investigating
| traffic patterns in which case it can be clearer when it's 6pm
| local time rather than noon utc or whatever. Embedding that in
| the returned timestamp can save another field.
|
| However, for the forward looking/scheduling one one, if you
| want it to keep the same time across timezone/DST policy
| changes, you need to the full on timezone designator (i.e.
| America/New_York), not just the offset or short, ambiguous
| timezone code (EST).
|
| There's no allowance in ISO 8601 for this, so you need a side
| channel like another field to communicate this. I've seen other
| date formats do something like
| 2021-10-11T12:13:14[America/New_York] to allow for this. Once
| you do this, it probably makes sense to elide the offset to
| avoid the risk of consfusing mismatches between it and the
| timezone.
| ectopod wrote:
| As far as I know, there isn't an official standard for
| timezone names so you need to define which set of names you
| are using.
| Macha wrote:
| IANA tzdb is the defacto standard in the software industry.
| fanf2 wrote:
| One of the aims of RFC 3339 is to eliminate the ambiguous
| variants from ISO 8601, so it makes the timezone obligatory.
| Timestamps without a timezone are in an unspecified local time.
| willis936 wrote:
| Timestamps with a timezone are in UTC.
| sanderjd wrote:
| In my view what's best is to always pass around utc but include
| the Z to make it explicit that's what you're doing. It's a very
| succinct way to represent that and can be very valuable to
| disambiguate so I think it's worth the extra character.
| midasuni wrote:
| Sometimes you are defining a date by the local time.
|
| I have a meeting on June 13th 2026 at 15:00 london time.
|
| This could be 2026-06-13 14:00:00 Z
|
| But if the U.K. drops summer time, or makes it double summer
| time, the meeting will still be 1500 london time, but the UTC
| time might change to 1500Z or 1300Z
| zestyping wrote:
| Because the digits are of varying widths in the standard Apple
| system font, the ticking seconds cause the date strings to jiggle
| back and forth and the table column widths to jiggle as well!
|
| However, you can use CSS to select the fixed-width variant for
| digits. This is a perfect example of a use case for:
| * { font-variant-numeric: tabular-nums; }
| yeetaccount wrote:
| All this just makes it clear to me that we need a time standard
| which addresses all the problems and of ISO8601. It'll be painful
| until it's universally adopted, but once it is we'll be in
| timekeeping heaven.
| vslira wrote:
| As someone who frequently works with datetime data, I always felt
| that in the format YYYY-MM-DDTHH:mm+-ZZ:ZZ, it should read "this
| local time plus the timezone offset gives you utc", not " utc
| plus the timezone offset gives you this local time", so basically
| invert the signal from how it is now.
| gnulinux wrote:
| But then they wouldn't be lexicographically sortable.
| venthur wrote:
| I'm surprised that neither of them has standardized the quarter,
| i.e. 2021-Q1. This is fairly common in business.
| cmclaren wrote:
| ISO 8601-2:2019 defines quarters in section 4.8, "Sub-year
| groupings". Your example of "2021-Q1" can be represented as
| "2021-33".
| venthur wrote:
| Unfortunately the document is not freely available. Can you
| elaborate how it works?
| cmclaren wrote:
| The latest standard (2019) is divided into two parts: ISO
| 8601-1 and ISO 8601-2. Part 2 is titled "Extensions" and
| includes many different - but optional - ways to extend
| representations of dates and times. In my opinion, Part 2
| represents the "leftovers" - that which was too domain
| specific or esoteric to warrant broad implementation.
|
| Representations of seasons, quarters, etc. is one of many
| types of extensions included in Part 2.
|
| These extensions are always used in "YYYY-MM" format (and
| always include the "-"). For the "MM" field, you use the
| numbers 21-41 inclusive. The numbers represent, in order,
| spring, summer, autumn, and winter, in 3 ways: independent
| of hemisphere (21-24), northern hemisphere specifically
| (25-28), southern hemisphere specifically (29-32); quarters
| 1-4 (33-36), quadrimesters 1-3 (37-39), and finally,
| semestrals 1-2 (40-41).
| tgsovlerkhgsel wrote:
| This, in combination with the fact that the lookup table
| is paywalled, makes it a great competitor for the
| "extremely pointlessly overengineered standards" award.
|
| I wonder if there is _any_ software that actually
| supports that.
| goldenkey wrote:
| Where's the 33 come from?
| [deleted]
| cmclaren wrote:
| There is a list of "Sub-year groupings" which assign two-
| digit numbers to seasons (hemisphere independent), seasons
| (Northern Hemisphere), seasons (Southern Hemisphere),
| quarters, quadrimesters (four-month periods), and
| semestrals (six-month periods). The numbering starts at 21.
|
| The numbers 1 to 12 are already used to represent months in
| formats such as YYYY-MM, so starting this list higher than
| 12 allows these (certainly rare) representations to
| coexist. e.g. "2021-12" represents "October, 2021" and
| "2021-29" represents "Spring, Southern Hemisphere, 2021".
| iwwr wrote:
| Quarter depends on reporting periods, or fiscal year, which
| does not match calendar year everywhere.
| dotancohen wrote:
| > which does not match calendar year everywhere
|
| Yes, this is the reason that ISO-8601 ranges are not
| sufficient and a Quarter indicator is necessary.
| marcosdumay wrote:
| The problem is that if you carry the string '2021-Q1'
| across countries borders, the days it represents change.
| That makes for a very bad time interchange format.
|
| I agree that this feature makes quarter indicator
| necessary. But it also makes it required that the string is
| something more complex.
| dotancohen wrote:
| If you carry the string '2021-10-24' across countries
| borders, the moments in time that it represents change as
| well.
|
| That makes doesn't make it a bad time interchange format
| for certain use cases, though. Just like everything else
| with time, one must be aware of caveats. Those include
| timezones, leap periods, culture, DST, formats,
| legislation (modern and ancient), etc.
| remram wrote:
| But it overlaps. It's off, but less than 100% off.
|
| "2021-Q1" can be a completely different and non-
| overlapping range between regions, and even between
| companies in the same region.
| naniwaduni wrote:
| 2021-10-24 in UTC+14 (Line Islands) and UTC-10 (Hawaii)
| are, in fact, 100% off.
| remram wrote:
| Yeah the Line Islands are the exception as always.
| pletnes wrote:
| The use of colon in timestamps is incompatible with several
| filesystems and this just drives me nuts.
| yeetaccount wrote:
| It doesn't take long to get used to the basic format.
| 20211024T090755, etc.
| LinAGKar wrote:
| By "several filesystems", you mean Windows? NTFS can handle it,
| but Windows can't (presumably due to using it for drive
| letters).
| boondaburrah wrote:
| ':' was the traditional directory separator on Macintosh
| systems before OSX, therefore it can't be used on HFS+
| either. I remember there being some FS funk when OSX came out
| since it was very common for people to put dates in their
| filenames using slashes, and well, UNIX doesn't like that. I
| don't know what APFS does.
| fanf2 wrote:
| As I understand it, : and / get swapped depending on
| whether you use unix APIs (/ is a directory separator, : is
| plain) or mac APIs (: is a directory separator and / is
| plain)
| pletnes wrote:
| From what I recall (had a macbook years ago) I could put
| colons in filenames in the terminal, but not in finder.
| rogerbinns wrote:
| NTFS can't have colons in filenames because they are used to
| name alternate data streams.
|
| https://docs.microsoft.com/en-
| us/sysinternals/downloads/stre...
| dvh wrote:
| Me too, I'm usually using 2021-10-24--13-07-59
| jacobmischka wrote:
| I use `--` to represent an en dash for date ranges
| (some_report_2021-01-01--2021-12-31). I don't use times
| nearly as often, but I separate date from time using an
| underscore in those instances.
| Dunedan wrote:
| Fun fact: If you download a file containing colons with popular
| web browsers, they'll try to be helpful and will replace the
| colons to avoid problems storing the file on filesystems which
| don't support colons. Took me a while to figure out why the
| browsers messed with the file names.
| uwu wrote:
| chrome's extension api for downloads has the same limitation
|
| filenames that are reserved names on windows (like NUL) or
| contain characters that are reserved on windows are refused
| with "Invalid filename", even on platforms and filesystems
| that don't have the same limitations
|
| this might be desirable for enforcing portability in
| extensions, but the thing isn't mentioned in the
| documentation[1] for the api so you had to know about it
| beforehand (like most extension devs, probably) or find out
| the hard way when some of your downloads unexpectedly fail
| (like me)
|
| i was using it on linux in a personal extension i wrote, and
| i thought it was silly that i had to add extra code to
| further sanitize and mangle the filenames for an OS i don't
| even use
|
| [1] https://developer.chrome.com/docs/extensions/reference/do
| wnl...
| ketzu wrote:
| I just wish there was proper support and UX for dates on file
| systems, so I can actually properly search for date ranges
| instead of having "iso8601 sorts lexicographically!" as a
| crutch used within filenames.
| kortex wrote:
| I use 2021-10-24T10_45_32_123456. Never had to store non-UTC so
| I'm not sure how I'd notate that. I don't use dots for
| fractional seconds because while that _shouldn 't_ get
| interpreted as an extension, some systems still do.
| gorgoiler wrote:
| ...and none of these do timezones properly! If your birthday
| party is:
|
| _2022-05-01T16:00+1000_
|
| ...but tomorrow's government abolishes daylight savings time,
| your birthday event has to change to:
|
| _2022-05-01T16:00+0900_.
|
| If you'd just said:
|
| _2022-05-01T16:00 Asia /Eastern_Siberia_
|
| ...you'd be fine and everyone will show up at the right time.
| kstenerud wrote:
| This is the biggest reason why I had to develop a new time
| format for Concise Encoding :/
|
| https://github.com/kstenerud/concise-encoding/blob/master/ce...
|
| https://github.com/kstenerud/concise-encoding/blob/master/ct...
|
| ISO 8601 and RFC 3339 are only useful for times in the past
| (which works fine for most internet protocols because they're
| only interested in recording events).
| kortex wrote:
| I was going to give you the usual "now there are 15 different
| standards" but this is actually really well thought out.
|
| How does it handle leading zeros in the year, like Long Now
| likes to do? https://blog.longnow.org/02013/12/31/long-now-
| years-five-dig...
| kstenerud wrote:
| For the text variant, it just parses the year field as an
| integer, so leading zeroes would generate the same year
| value as if you'd omitted them.
| kortex wrote:
| Nice, that's the parsimonious way to handle it.
|
| I'm really digging this system in general. I hope it gets
| more traction.
| dmurray wrote:
| On the other hand, valid data may now be unreasonably
| long. What if someone gives you a string that starts with
| 10^12 leading zeros?
| kstenerud wrote:
| This is where security and limits comes in:
|
| https://github.com/kstenerud/concise-
| encoding/blob/master/ce...
| throwaway09223 wrote:
| What's wrong with TAI?
|
| Using a date format for precise time types doesn't make much
| sense because human readable date formats are inherently tied
| to orbital mechanics[1] (days) and social constructs
| (timezones, calendars, laws, etc). Better to just record
| seconds from an epoch.
|
| I see you mention leap seconds in your specification, but you
| don't address how to handle time in the future given that
| leap seconds can't be predicted more than 6mo in advance.
| This is a key feature of TAI -- no synchronization to earth's
| orbital mechanics. No leap seconds to keep the sun overhead
| at noon. This means your time spec will likely be off by
| seconds when using dates more than 6mo out. It seems like
| your format is also only useful for recording past dates.
|
| [1] TAI is still tied to earth's frame of reference, of
| course. At some point when we get more serious about space,
| timestamps will need to include location and velocity. This
| is already a problem even on the scale of earth satellites
| and I don't think anyone's yet created a standard.
| kstenerud wrote:
| There are a few reasons:
|
| - The text format is designed for human reading and input.
| Nobody is going to understand TAI, or bother to look it up.
| They're going to enter time like they see on their clock.
|
| - Special time representations like TAI require a bunch of
| complicated machinery to convert to/from a human-friendly
| format. It's complicated, requires regular maintenance, and
| implementations have varying levels of buggy. Keeping it
| human-friendly in the first place eliminates this whole
| class of problems.
|
| - Leap seconds are already a thing because of the above two
| reasons, and they're not going away since we're not going
| to change humanity's understanding of time to something
| more precise.
|
| We're perfectly capable of handling future dates beyond 6
| months without using TAI (and keeping our clocks in sync
| well enough to be on time).
| throwaway09223 wrote:
| The special representation isn't TAI (seconds from
| epoch), the complex and special representations are the
| human readable formats. It's the human formats that
| incorporate intractable aspects of solar mechanics, law,
| and geography. TAI is the simple answer here.
|
| It looks like you have a human readable (CTE) and binary
| format (CBE), and you use human-style formatting for the
| computer readable binary format. This seems incongruous
| to say the least, especially when I look at how you're
| representing other numeric types.
|
| While human readable formats are complex, there are
| standard functions which generate them from epoch time.
| It's trivial to do this in a display layer, and strongly
| recommended architecturally speaking.
|
| Also, leap seconds _do_ go away if you use TAI. That 's
| the entire point of TAI. Leap seconds are a display layer
| issue, just like time zones. They can be applied when
| translating an epoch to a localized format.
|
| You cannot have seconds-level granularity with the way
| you've designed your time format. Sorry, but this is just
| a fact.
| kstenerud wrote:
| Yes, the "simpler" representation is TAI, but we still
| live in a human world, and with humans entering and
| reading the data we must conform to their ways in some
| things.
|
| The binary and text encodings both store in Gregorian so
| that codecs don't have the added responsibility of
| converting between representations (keeps the
| implementations simple).
|
| TAI is like lye: useful, but not meant to be handled by
| humans. And since this format is designed for human
| usability, human time wins the day.
| CameronNemo wrote:
| _with humans entering and reading the data we must
| conform to their ways in some things_
|
| I don't understand what is stopping you from converting
| from tai to human readable and vice versa at the
| form/input and display/output layers, respectively.
| throwaway09223 wrote:
| Well, I guess we'll have to agree to disagree.
|
| When I look at human readable logfiles I see a trend
| towards using epoch seconds for exactly these reasons.
| It's so easy to convert, it outweighs the anti-usability
| aspects inherent in formatted strings. I've converted all
| my own human readable file formats to epoch times for
| exactly these reasons and my customers seem to strongly
| prefer it.
| sltkr wrote:
| You're conflating two separate use cases. The point of the
| numerical-offset notation is exactly to denote a fixed point in
| time.
|
| For the birthday party example: it's not a given that I want to
| reschedule it when the local time zone changes (maybe I want to
| meet before sundown so we can sit outside? in that case, I
| would want to adjust the local time, keeping the solar timethe
| same). Sometimes of course, it is desirable (think of the
| opening hours of a shop, for example), but that's a separate
| use case.
|
| Similarly with online events involving international guests: if
| you move an event to keep the local time unchanged, this change
| might create conflicts on other people's calendars. It's not
| necessarily the desired outcome.
|
| Another problem with including a time zone name is that not
| everybody has the same version of the time zone database. At
| worst, that means that different people will have different
| interpretations of which point in time is being described. At
| best, the result will only be eventually consistent.
| gorgoiler wrote:
| The international online-meeting corner case is interesting
| but I think you're off the mark for the most common use case
| for these kinds of human readable time stamps: the local
| event begins when the local calendar shows the given date,
| and the local wall clock shows that particular time.
|
| My birthday party begins next year on May 1st when both our
| Siberian clocks say it is 4pm.
| ethbr0 wrote:
| Exactly. (Fixed objective time) -> (current subjective time)
| is a problem with enough nuances that you probably don't want
| your format making assumptions for you.
|
| Look up the Japanese calendar, if you want some fun: https://
| en.m.wikipedia.org/wiki/Date_and_time_notation_in_Ja...
| zauguin wrote:
| Every year when DST ends, there are two hours during which the
| locale name based time is not unique since it could be both
| shortly before or after the time got turned back.
|
| But beside that this would make sense when everyone involoved
| is living in the same timezone, but when coordinating
| internationally (which tends to be the main focus when the ISO
| is involved) we really do not want such changes to happen
| automatically. Everyone in the local timezone is likely to be
| aware of time changes so they know they have to adapt, but
| everyone in another timezone might have almost no way of
| knowing. For them, an event starting at a different (UTC) time
| is a rescheduling, no matter if it is caused by some timezone
| adjustment or not. So hiding this behind some tzdb change
| instead of sending out new dates would most likely mean that
| they appear at the wrong time.
|
| Also including offsets ensures that the person writing the time
| knows the right offset. In the last year, I had quite some
| meetings where the host wanted to be nice and send the time in
| the local timezone for every participant. Since only timezone
| names and no offsets were included and the host mostly assumed
| that their local DST rules apply globally, this resulted in a
| giant mess. Especially after people informed them about errors,
| so the times switched back and forth between times assuming DST
| or not assuming DST. Without seeing the offset, there was no
| way of knowing which time was actually intended. If a UTC
| offset is given, most local people can relatively easily verify
| that it is the expected offset but even more importantly, you
| can independently convert it to the right zone no matter what
| the author thought.
| umanwizard wrote:
| That's still ambiguous, since the government might only abolish
| DST for _part_ of Asia /Eastern_Siberia, causing the zone to
| split.
| 0xbadcafebee wrote:
| I guess we could just put the lat/long and let people figure
| it out? But that still doesn't fix the time when the time
| zone does change... So using UTC is a simple fix
| ComputerGuru wrote:
| UTC doesn't fix anything if you meant 6pm my local time on
| that day, come hell or high water.
|
| Eg: Work at the local library is always 9 to 5 (again
| "local time") and you mean precisely one hour after work
| lets up, regardless of whatever daylight savings or time
| zone changes occur between now and then.
|
| You need to use either a naive date-time representation
| coupled with the additional context ("my time") or use
| something like lat/long. Or you're lucky and you live in or
| near enough to a major metropolis that has its own TZDB
| entry and it's virtually impossible for your local time to
| diverge from that TZ, so you can use that instead (eg you
| live just outside NYC proper so you use America/New_York as
| your time zone).
| kbenson wrote:
| Your example alludes to why there will always be a rift
| between UTC and local representations. Unless your system
| can understand "one hour after I end work for the day"
| correctly, any representation of that time will be
| subject to not just local timezones changes, but local
| work conditions for one or a few people (otherwise it
| can't be assumed a single time instance).
|
| One is a a representation stripped of most ornamentation
| to be universally agreed upon, the other is a
| representation with many additional layers of context so
| it's locally understood.
|
| There will likely always be a trade off between these, as
| a universal time is useful in all cases for only a small
| group of people, while a local time quickly loses
| relevance out of a local context.
| ComputerGuru wrote:
| Meh. You live in Gary, IN and you specify the birthday party as
| 2022-05-01T16:00 America/Chicago but your state representatives
| lobby to stop using Chicago time because remote work obviated
| that need and suddenly you're actually supposed to be using
| America/Indiana/Indianapolis as your TZ.
|
| It's ugly whatever you do, unless you use coordinates to
| specify your time zone (then it's just hell to decode).
| computerfriend wrote:
| If your birthday party is 2022-05-01T16:00 Asia/Eastern_Siberia
| but you said 2022-05-01T16:00+1000 instead, then you made a
| mistake.
|
| If it's really at 2022-05-01T16:00+1000, then it doesn't matter
| what DST policy changes occur.
| gorgoiler wrote:
| The point of a future timestamp + tzdb timezone is to
| twofold:
|
| 1/ my birthday party will start when my watch shows this
| local time and date
|
| 2/ my local time and date are dictated by the legislative
| body responsible for this geographic area.
| tgsovlerkhgsel wrote:
| The one big failure of RFC 3339 is that it doesn't specify the
| actual rules for the separator: Applications
| using this syntax may choose, for the sake of
| readability, to specify a full-date and full-time separated by
| (say) a space character.
|
| Is separating it by a tab valid? A tilde? An underscore, as this
| website shows? Since this is so underspecified, there will be
| receivers that accept only T, and others that accept the T and
| some arbitrarily chosen character set. The ABNF only allows T.
|
| I don't know how a standard that was specifically written to
| resolve the issues resulting from such ambiguities ended up with
| such a crucial issue.
| TacticalCoder wrote:
| I never really thought about six-digits years (I don't really
| understand what is meant by "by mutual agreement"): is this
| something in use today and by whom? Who needs six-digits years
| and _only_ six digit years? I mean: if you 're projecting stuff
| in the future (like, say, continental drift), you'll be stuff at
| year 99999 and have the exact same problem of wrapping around
| back to zero when you'd need year 1000000 no?
|
| Or is it "infinite": as in, the spec allows for 8-digits years,
| 10, etc.?
| cmclaren wrote:
| The spec permits more than 4 digits for 'year' by mutual
| agreement. This is called 'expanded representation'. There is
| no limit to the number of digits, but parties need to agree on
| how many additional digits will be used to avoid ambiguous
| representations.
|
| Consider that +002021001 could represent:
|
| a) "Oct 1, 202" as a calendar date (proleptic Gregorian), in
| 'basic' format (i.e. no "-" separator), 5 digits for year.
|
| b) "Jan 1, 2021" as an ordinal date, 'basic' format (i.e. no
| "-" separator), 6 digits for year.
| amelius wrote:
| I wonder how useful more than 4 digits would be. Once our
| species has achieved interstellar travel, we'll probably use
| a completely different representation for time.
| pdw wrote:
| Some musea need more than 4 digits to describe their
| collection...
| amelius wrote:
| Yeah, but they also need a minus sign.
| cmclaren wrote:
| By default, ISO 8601-1:2019 does not permit negative
| years in date representations.
|
| Expanded representation (i.e. five digits or more for the
| year) permits both positive and negative years (and the
| sign is mandatory for both positive and negative years).
|
| ISO 8601-2:2019 has provisions for numeric extensions.
| Subclause 4.4.1.2 permits negative four-digit years
| (years -9999 to -0001).
|
| Note that both of these options require mutual agreement.
| Klaster_1 wrote:
| https://news.ycombinator.com/item?id=24453612
| neoeno wrote:
| One use: I was teaching some developers COBOL, and I wanted
| to illustrate for them how the Y2K bug came about.
|
| So I gave them a project to do parsing a file with
| contemporary dates in. Then towards the end I quietly
| supplied them with a similar file containing dates from the
| year 10000+.
|
| Whether or not the devs of years past felt it similarly
| unlikely that their software would live to the year 2000 as
| we do the year 10000, I don't know. But it was a fun
| exercise!
| heavenlyblue wrote:
| Don't forget that when Y2K problems were being created
| the hardware was _way_ less performant than the hardware
| of today. There was a reason to be wary of how much
| memory you are using, now there isn't much.
| ethbr0 wrote:
| > _Once our species has achieved interstellar travel, we
| 'll probably use a completely different representation for
| time._
|
| All experience thus far suggests "No." We'll be using all
| of these formats, plus some new ones.
| TheCoelacanth wrote:
| What date formats from 8000 years ago are still in use?
| ethbr0 wrote:
| Solstice and equinox-relative seasons?
| gerikson wrote:
| I've seen 5 digit years in use online in some places, but not
| 6-digit (so far). Maybe it's influenced by the Long Now
| project?
|
| For long timescales (geological deep time) I believe using SI
| units are more appropriate:
| https://en.wikipedia.org/wiki/Year#SI_prefix_multipliers
| em500 wrote:
| This is very neat, but maybe not completely accurate. "2021-10-24
| 11:02:03Z" is outside iso8601 in the figure, but I think it's
| valid iso8601. True, "T" is the One True date-time separator in
| iso8601 (IMO its biggest wart, as it looks awful for human eyes:
| "2021-10-24T11:02:03Z"). But according to the draft standard[1],
| page 21:
|
| > By mutual agreement of the partners in information interchange,
| the character [T] may be omitted in applications where there is
| no risk of confusing a date and time of day representation with
| others defined in this International Standard
|
| [1] The actual ISO standard is not freely available, but the
| Library of Congress has free draft standards:
| https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i...
| https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_i...
| colejohnson66 wrote:
| Tangent: what's the point of these "international standards"
| when I have to pay to know the standard I'm following? Sure, I
| can use final drafts, but I shouldn't have to.
|
| It honestly seems like a racket. Businesses collaborate to
| write a standard that costs hundreds of dollars, and then brand
| new small businesses can't afford to assert that they follow
| them.
| superjan wrote:
| It is great when standards become free, but then we need to
| agree how else to fund the standardization process. Taxpayer
| money?
| kps wrote:
| For the 'ISO' standards where I'm aware of the process,
| development was funded by the participants. ISO is just a
| rent-seeking gatekeeper, like academic publishers.
| dv_dt wrote:
| As I have encountered it, the vast cost of the
| standardization process is already borne outside of ISO
| because creation and update of the standards is done by
| outside participants. Hosting the standards documents is a
| minuscule cost and fees seems mostly a holdover when
| potentially large bound physical document publishing and
| distribution was involved.
| superjan wrote:
| I know they don't subsidize standard development. But
| there is still cost for running an organization to manage
| and coordinate (and maybe translate) what is being
| standardized over hundreds of topics. Of the 40 million
| in total income, selling standard documents is 1/4 to 1/3
| of their income. You don't pay for the cost of electronic
| copies, but for running the organization.
|
| source: https://www.iso.org/files/live/sites/isoorg/files
| /store/en/P...
| everybodyknows wrote:
| There's a parallel dysfunction in California, where the
| legally-enforced version of the electrical code is
| available on paper only, at a price of $224:
|
| https://catalog.nfpa.org/NFPA-70-National-Electrical-Code-
| wi...
|
| In democracies it seems taxpayer money can only be had for
| purposes that please some fraction of the legislators.
| bluGill wrote:
| There is a cost to make a standard. Somehow that needs to be
| paid.
|
| Though iso isn't really spending its own money from what I
| can tell, so I don't see where their costs are coming from.
| tgsovlerkhgsel wrote:
| That seems like a great use for taxes. I suspect the
| economic benefits from the easy accessibility of the
| standards (just imagine the cost of the approval processes
| to buy the standards and handle access, plus the cost of
| the standards remaining inaccessible to smaller players)
| would outweigh the financial costs.
| colejohnson66 wrote:
| That's what I'm getting at. The committees are generally
| funded by big companies who basically sign the rights over
| to ISO. ISO then charges you hundreds of dollars for a
| single PDF of a standard (which may contain over a dozen).
|
| It reminds me of scientific journals that do nothing but
| charge money for other people's work. It reeks of rent
| seeking.
| dwheeler wrote:
| ISO doesn't pay to develop standards, they assume others
| will develop the standards.
|
| Historically, the purpose was to pay for printing &
| distribution. That makes no sense _today_ , but that was
| its historical justification.
| [deleted]
| ethbr0 wrote:
| If they just sold test validators and certification services
| instead ("Certified by ISO"), it'd be such a healthier
| dynamic.
| marcosdumay wrote:
| ISO shouldn't sell anything. It doesn't have a profit
| motive and can be financed by governments without any
| problem.
| kbenson wrote:
| Can and will are two separate things, and even if it
| happens then you get countries trying to influence
| decisions with the threat of stopping funding.
|
| That's not to say it wouldn't be better, just that it's
| not without its own problems.
| rdpintqogeogsaa wrote:
| It's correct. Omission means 2021-10-2411:02:03Z, not replacing
| it with a space instead.
| grey_earthling wrote:
| Omitting the hyphens and colons is allowed too (IIRC), so I
| suppose omitting the T is intended for cases like
| 20211024110203Z -- which IMO is a sensible format when
| there's no ambiguity that this is a date-time.
| jfrunyon wrote:
| That's a sensible format only for interchange - humans need
| separators to read it...
| kbenson wrote:
| They don't _need_ it. It makes it easier, but if you know
| it 's a date and time format, it's pretty easy to read as
| long as you take care to keep track at which characters
| your looking at.
|
| Justlikehowinmostcasesepacesmakeiteasiertoreadsomethingbu
| taren'trequired.
| LinAGKar wrote:
| So that should also be in the dashed circle.
| Arcorann wrote:
| There are some non-trivial changes between the draft standards
| and the final ISO 8601:2019-1 standard, one of which relates to
| making the use of T stricter, and the mentioned provision was
| removed.
|
| Regardless, ISO 8601 has generally discouraged using spaces
| within expressions. From ISO 8601:2004, section 3.4.1:
|
| > Unless explicitly allowed by this International Standard the
| character "space" shall not be used in the representations.
|
| Similarly, from ISO 8601:2019-1, section 3.2.1:
|
| > The character "space" shall not be used in the expressions.
|
| However, through looser interpretation of the standard,
| "2021-10-24 11:02:03Z" could be allowed if treated as a date
| representation followed by a space followed by a time
| representation (note that the formal time representation in ISO
| 8601:2019-1 is T11:02:03Z, but it allows omission of T for
| extended format as per 5.3.5).
| concordDance wrote:
| > There are some non-trivial changes between the draft
| standards and the final ISO 8601:2019-1 standard, one of
| which relates to making the use of T stricter, and the
| mentioned provision was removed
|
| Yes, and? The draft standard is the pretty much everyone
| actually uses. For most purposes it's the "real" one.
| mlyle wrote:
| Robustness principle. There's no way you should be relying
| upon a draft to emit things that violate the real standard.
| [deleted]
| convolvatron wrote:
| there is never any final difference...since you work in a
| group, and every change is vetted, it only gets ratified
| when everyone says 'yep, no more changes'
| letmeinhere wrote:
| ISO business model is so strange; in order to make money they
| have to hide the actual standard from the vast majority of
| engineers that it relates to, so we just assume whatever was
| proposed was close enough.
| marcosdumay wrote:
| Yes, on practice the draft becomes the actual standard.
|
| That is, unless it's in a regulated industry that is
| required by law to follow the actual standard. Then it
| disobeys the law most of the time, and "disobey" the market
| the rest of the time and everything breaks. Also, it leaves
| the people with a secret law that nobody can know the
| consequences.
|
| The ISO governance should be changed ASAP. It was never
| good, and nowadays it's a disaster.
| dv_dt wrote:
| Yup, I wonder if an issuing group pays a fee on new
| versions as well as a maintenance fee would work out.
| skissane wrote:
| > The ISO governance should be changed ASAP. It was never
| good, and nowadays it's a disaster.
|
| ISO was founded in 1947, and back then very many of its
| standards were about physical objects - pipe threads,
| screws, bearings, belts, film, steel, plastic, rubber,
| textiles, etc - and even today they still have many
| standards on those kinds of topics. Imagine you are an
| aerospace engineer in the 1970s, and you need a copy of
| the new standard ISO 46:1973 (Aircraft -- Fuel nozzle
| grounding plugs and sockets) - if nobody at your work has
| a copy, you just order it and pay for it with the
| company's money (expense it, get your boss to sign the
| purchase order, whatever). Nobody would have a problem
| with that and you wouldn't think there was anything
| inappropriate about it either, it would just seem totally
| normal to anybody in the 1970s.
|
| The problem is that technology and culture have changed
| and ISO hasn't kept up - especially for software-related
| standards. We are an industry in which there are lots of
| independent contractors and self-employed people and
| small businesses, it is easy to be self-taught, in which
| multi-billion dollar companies will charge millions for
| software packages and then include in their code some
| open source library that someone maintains as an unpaid
| hobby, in which many employers baulk at paying for things
| which in prior decades employers would have just paid for
| without question. The culture has changed from one in
| which people are used to paying money for physical books
| in person or via mail order, to one in which they expect
| to get information from the Internet instantaneously and
| for free.
|
| And it is probably mostly in software that people
| complain about this. I could be wrong, but I would guess
| that for aerospace engineers it is no more an issue today
| than in the 1970s. Even if ISO were to charge a few
| hundred dollars for a standards document, it would still
| be a lot cheaper than most things aerospace engineers
| deal with, and your employer will pay for it, who cares.
| At big firms such as Airbus or Boeing, they probably have
| some kind of subscription so their engineers just get
| access to all new ISO standards automatically.
| ademarre wrote:
| _> software-related standards. We are an industry in
| which there are lots of independent contractors and self-
| employed people and small businesses, it is easy to be
| self-taught_
|
| Consider also the pace of innovation in software and
| networking--the internet at large. I think it's both a
| consequence and a cause of the change in culture you
| described.
| ademarre wrote:
| There are very many things I never would have discovered
| and learned if IETF RFCs were not free. The most useful
| knowledge I've acquired about building things on the
| internet came from there.
|
| Industries that are more reliant on ISO or other non-free
| standards are surely worse off because of it.
| cmclaren wrote:
| Your example is valid in ISO 8601-1:2019.
|
| There are only two possible representations for which "T" is
| required: hh or hhmm in 'basic' format (i.e. no ":" separator).
| The former could be confused with a two-digit century, the
| latter could be confused with a four-digit year. Adding "T" to
| hh or hhmm solves this.
|
| Any of the following eliminates the "risk of confusion":
| - 'extended' format (hh:mm) - decimal fraction (hhmm,m or
| hh,h; see 5.3.1.4); - UTC designator (hhmmZ or hhZ; see
| 5.3.3), or; - time shift (hhmm+-hhmm, hhmm+-hh, hh+-hhmm,
| or hh+-hh; see 5.3.4).
|
| Also worth noting: hhmmss in 'basic' format (i.e. no ":"
| separator) does not pose a risk of confusion, as YYYYMM in
| 'basic' format (i.e. no "-" separator) is not permitted by the
| spec.
| emilfihlman wrote:
| Still missing the best
|
| %F %T %z
|
| (Ie %Y-%m-%d %H:%M:%S %z)
|
| Though adding nanoseconds is also recommended.
| est wrote:
| on Python 3.6, the %X gives 14:09:44. Is this a intended or a
| bug?
| emilfihlman wrote:
| Imho that does sound like a bug. %X should give a dot
| separated time, like 22.47.30
|
| You can live test according to Linux man-pages project,
| release 4.14 at emil.fi/p/strftime (sorry about the css, it
| seems it's broken a little bit, you can use the "use desktop
| site" selection to have it behave better).
| iimblack wrote:
| Is there a reason to not just use Unix timestamps? That's how
| I've been passing datetimes in my api and storing them in my db.
| kbenson wrote:
| As long as you're sure they're all based on the same start time
| and not off by +/- 12 hours, no. One of the reasons a UTC+TZ
| format is useful is that it makes clients be explicit about
| this.
|
| This may or may not be a problem you need to worry about in
| your API depending on use and clients. For example, if you're
| only ever sending times and not accepting them, you can just
| define that the epoch you return is based on UTC or locally and
| let clients real with it.
|
| If you don't care about pre-epoch times, then it's a compact
| and fine representation for the DB, single they all have easy
| conversion functions to their internal formats
| bla3 wrote:
| https://datatracker.ietf.org/doc/html/rfc3339 says that rfc339 is
| a"profile of iso8601" -- shouldn't it be a true subset?
|
| Also, I read through that RFC several times and didn't find where
| it allows replacing 'Z' with space. Can anyone else find it?
| rdpintqogeogsaa wrote:
| Section 5.6:
|
| > _NOTE: ISO 8601 defines date and time separated by "T".
| Applications using this syntax may choose, for the sake of
| readability, to specify a full-date and full-time separated by
| (say) a space character._
| bla3 wrote:
| Thanks!
|
| Seems to contradict sections 5.2 and 5.5 in spirit...
| merb wrote:
| do you now whats ridiculous? that we germans (and europeans) also
| use the iso 8601 but it's still allowed to use din 5008 and the
| european date and time notations... WHY??? it's so stupid to use
| dd.MM.yyyy, it's worse in every way to yyyy-MM-dd. worse than
| that the old notation is preferred in most official
| documents..... WHY....
| tgsovlerkhgsel wrote:
| Because unless you start fining or imprisoning people for using
| the wrong date format, people don't care what you write in a
| law book and will continue to use what they're used to if it
| works well enough.
|
| Allowing DIN 5008 simply acknowledges reality. Not
| acknowledging reality is a good way to make people decide that
| whatever is telling them they're doing it wrong is just "ivory
| tower" nonsense and should all be ignored at best, possibly
| actively opposed.
| hendry wrote:
| RE time standards, I always thought it was interesting how WHATWG
| took a subset of ISO 8601 since ISO went off the rails wrt poorly
| defined complexity.
|
| https://html.spec.whatwg.org/multipage/common-microsyntaxes....
| jacobmischka wrote:
| I like the concept of ISOs in general, but I personally prefer
| RFC 3339. The space makes it so much easier to read at a glance,
| and I can't imagine it makes parsing much different
| algorithmically?
| smitty1e wrote:
| Space characters affect processing in shell scripts, so one
| manages them closely, along with colons, as noted elewhere.
| remram wrote:
| In what context would you prefer ISO over RFC? The fact that
| ISO standards cost hundreds to read and apparently change over
| time, while RFCs are openly available and get replaced if
| necessary, makes it hard for me to see ISO as more than a
| crutch. If there's an open standard, I'll use that, and people
| will actually know what I'm talking about.
| jacobmischka wrote:
| I agree with everything you said. I guess I just naively like
| the idea of an international standards organization in
| theory, though I suppose that's also essentially what the
| IETF is too.
| Zekio wrote:
| I keep hoping the whole world will switch to a single timezone
| utc, that way so many things would be simpler
___________________________________________________________________
(page generated 2021-10-24 23:00 UTC)