7 ms·
It's an international standard: https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601
by timdoug 13y ago
It's an international standard: https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601
- SideburnsOfDoom 13y agoThere are two ways to send dates across the wire as text between different systems: 1) ISO 8601 2) A world of hurt Source: experience. Not using the standard invites things to break, but only on a some machines, and only on or after the 13th of the month. Of course the data for the first few days of the month will be present, just wrong.
- NickNameNick 13y agoAnd always - always - always in UTC.
- ygra 13y agoAnd sadly there are still things that insist on using the second option. RFC 2822 used in MIME (historical oddity because it pre-dates ISO 8601), UNIX timestamps as either seconds or milliseconds (at work we have one instance where numbers > 32 bit are serialized as a hex string in JSON, which includes such a millisecond-UNIX-epoch timestamp), etc. Slightly related insanity: Using localtime (i.e. not UTC) for log timestamps. And then having fun once a year dissecting the one hour that has twice as many messages.
- hessenwolf 13y agoIt's annoys me that the time format with colons means I cannot use it for file names. What do you use instead?
- SideburnsOfDoom 13y agoSome other innocuous separator character such as underscore, or none, just fixed lengths for the numeric fields. But always, yyyy mm dd order.
- ygra 13y agoUnderscores work well, which results in "2013-12-16 10_22_57Z". I can still somfortably read it, at least. Hyphen-minus would lead to too easy confusion with the date part. Fixed-width fields can be hard to read.
- Semiapies 13y agoI just use HHMM at the end (or HHMMSS if you need that precision). Ex: 2013-12-16_1741.txt and the like.