3 ms·

I've heard of ISO 8601 timestamps but never 1606 (and neither has google it seems). What is that?

• bootload 19y ago
  You are dead right. I was wrong. I meant "ISO 8601". Late night post and I should have checked ~ http://www.ietf.org/rfc/rfc3339.txt http://www.ietf.org/rfc/rfc3339.txt
  • gojomo 19y ago
    From this RFC I learned that: Standard time in the Netherlands was exactly 19 minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through 1937-06-30. Those wacky Dutch!
    • bootload 19y ago
      "... From this RFC I learned that: ..." The bit I use is a bastardisation of "1985-04-12T23:20:50.52Z". A shorter version as a string, say "20070202T1422" stripping out the hyphens, colons and Zulu.
      • bayareaguy 19y ago
        Actually I don't believe "20070202T1422" is a legal 8601 timestamp. My read of the partial ABNF below requires you to designate the time zone with a "Z" or a specific offset (e.g. +08:00). time-secfrac = "." 1*DIGIT time-numoffset = ("+" / "-") time-hour ":" time-minute time-offset = "Z" / time-numoffset partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset date-time = full-date "T" full-time If your data is going to stick around a while (and possibly loaded into some other system in the future) you should be sure to encode the timezone.
        • bootload 19y ago
          "... 20070202T1422 is a legal 8601 timestamp. ..." 20070202T1422 - but close enough for me in 1 timezone and limited space for display. I have a double use as both a (8601 hack) and as a human readable title. Adding extra "-" and "Z" makes it harder to read and the accuracy for seconds is simply not required. Trade-offs I'm willing to make.