Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC 3339 vs. ISO 8601

ijmacd.github.io

Post reply on HN
Print view View original

111–120 of 177 posts

Re: RFC 3339 vs. ISO 8601

#111

Post by cmclaren »

venthur wrote: post #105
cmclaren wrote: post #36

Earlier quoted context omitted.

ISO 8601-2:2019 defines quarters in section 4.8, "Sub-year groupings". Your example of "2021-Q1" can be represented as "2021-33".

Unfortunately the document is not freely available. Can you elaborate how it works?

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).

Re: RFC 3339 vs. ISO 8601

#112

Post by kbenson »

marcosdumay wrote: post #64
ethbr0 wrote: post #53

Earlier quoted context omitted.

If they just sold test validators and certification services instead ("Certified by ISO"), it'd be such a healthier dynamic.

ISO shouldn't sell anything. It doesn't have a profit motive and can be financed by governments without any problem.

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.

Re: RFC 3339 vs. ISO 8601

#113

Post by gorgoiler »

sltkr wrote: post #43
gorgoiler wrote: post #37

…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.

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 desirab…

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.

Re: RFC 3339 vs. ISO 8601

#114

Post by kbenson »

jfrunyon wrote: post #89
grey_earthling wrote: post #22

Earlier quoted context omitted.

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...

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.

Justlikehowinmostcasesepacesmakeiteasiertoreadsomethingbutaren'trequired.

Re: RFC 3339 vs. ISO 8601

#115

Post by gorgoiler »

computerfriend wrote: post #67
gorgoiler wrote: post #37

…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.

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.

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.

Re: RFC 3339 vs. ISO 8601

#117

Post by kbenson »

ComputerGuru wrote: post #88
0xbadcafebee wrote: post #56

Earlier quoted context omitted.

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 someth…

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.

Re: RFC 3339 vs. ISO 8601

#118

Post by ectopod »

Macha wrote: post #8
willis936 wrote: post #2

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.

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 wa…

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.

Re: RFC 3339 vs. ISO 8601

#119

Post by emilfihlman »

est wrote: post #46
emilfihlman wrote: post #38

Still missing the best %F %T %z (Ie %Y-%m-%d %H:%M:%S %z) Though adding nanoseconds is also recommended.

on Python 3.6, the %X gives 14:09:44. Is this a intended or a bug?

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).

Re: RFC 3339 vs. ISO 8601

#120

Post by kbenson »

iimblack wrote: post #116

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.

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

Post reply on HN