The use of colon in timestamps is incompatible with several filesystems and this just drives me nuts.
It doesn’t take long to get used to the basic format. 20211024T090755, etc.
RFC 3339 vs. ISO 8601
81–90 of 177 posts
Re: RFC 3339 vs. ISO 8601
#82Does 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.
Re: RFC 3339 vs. ISO 8601
#83Note 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...
Re: RFC 3339 vs. ISO 8601
#84All 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.
Re: RFC 3339 vs. ISO 8601
#85Does 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.
This site is notionally devoted to Unix timestamps, but it covers a few popular formats: https://www.unixtimestamp.com/
Re: RFC 3339 vs. ISO 8601
#86Earlier quoted context omitted.
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.
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.
2021-10-24 in UTC+14 (Line Islands) and UTC-10 (Hawaii) are, in fact, 100% off.
Re: RFC 3339 vs. ISO 8601
#87…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.
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).
Re: RFC 3339 vs. ISO 8601
#88Earlier quoted context omitted.
That’s still ambiguous, since the government might only abolish DST for part of Asia/Eastern_Siberia, causing the zone to split.
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
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).
Re: RFC 3339 vs. ISO 8601
#89Earlier quoted context omitted.
It's correct. Omission means 2021-10-2411:02:03Z, not replacing it with a space instead.
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.
That's a sensible format only for interchange - humans need separators to read it...
Re: RFC 3339 vs. ISO 8601
#90Earlier quoted context omitted.
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 r…
> 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.
Robustness principle. There's no way you should be relying upon a draft to emit things that violate the real standard.