5 ms·
This is the very long tail of non-metric conversion that drives me insane. This date format is unforgivable: "td_id_fltdata_date": "00181219", (1) add in lead
by UI_at_80x24 7y ago
This is the very long tail of non-metric conversion that drives me insane.
This date format is unforgivable:
"td_id_fltdata_date": "00181219",
(1) add in leading 00 to allow for Y2k expansion (and then ignore it)
(2) DDMMYY This is unnecessarily "difficult" for a human and a computer to sort and parse. Using ALL the same number of digits and following ISO 8601 already solves this (and with the padding 00's you don't need to touch this part of the software for 7900 more years!)
20191218 - Done.
This can only be a holdover from a pre-PC era.
Some industries move at a glacial pace when updating standards and tools. The risk to lives because of screwups (i.e. a faulty radar at Air Traffic Control) is too great to do without sufficient study and experimentation. But this can only be an unwillingness to change.
- GhettoMaestro 7y agoProps to you for citing ISO 8601. Most folks don’t care :(
- kibwen 7y agoSee also RFC 3339, which seems to be a stricter dialect of ISO 8601. https://stackoverflow.com/questions/522251/whats-the-difference-between-iso-8601-and-rfc-3339-date-formats https://stackoverflow.com/questions/522251/whats-the-differe...
- somacert 7y agoOr as I like to call it, xkcd 1179 time
- beefhash 7y agoIt doesn't help that getting a copy of the actual standard costs an arm and a leg[1,2], especially if you want both parts of the 2019 edition. [1] https://www.iso.org/standard/70907.html https://www.iso.org/standard/70907.html [2] https://www.iso.org/standard/70908.html https://www.iso.org/standard/70908.html
- ChrisSD 7y agoTo be fair nobody* actually uses final ISO standards even if they refer to them. I think JPEG is an example of where the "draft" became the de facto official standard because that's what everybody used instead of paying for the actual standard.
- 0x8BADF00D 7y agoThere are certain industries where you need to care. Or many lives will be lost because of it. Always follow the standard, even if it takes extra time to implement.
- qw 7y agoReservation systems are built on top of very old systems. One date format that is standard is 25DEC19. It probably made sense for humans entering «cryptic commands» (yes that is the term)
- a1369209993 7y agoThat should be 1925dec19 (or 19dec1925 if you like little-endian), otherwise year vs day is ambigous.
- ryacko 7y agoNot between XX32 and XX00 as per last century.
- a1369209993 7y agoI think the past two decades have made it clear that that's a unacceptably brittle system.
- tgsovlerkhgsel 7y agoThe timezone also seems to use the same 'set some high flag bit for negative'-derived approach as the coordinates. But it's a float... converted to a string...
- pierrebai 7y agoI'm going to profoundly disagree with you here. These are not open-standards. These are not self-documenting, csv, receiver-has-to-guess formats. These are two on-board non critical systems talking to each other. The main requirement is that the format be specified. A desirable trait is that the format be easy to implement. Sorry, ISO 8601, you're too complicated for the task. Integrating a library to handle it is already too hard, too risky and over-engineering. You'd have to either trust it to be bug-free or heavily test it. KISS, remember?
- deleted 7y ago[deleted]
- jiveturkey 7y ago> (2) DDMMYY This is unnecessarily "difficult" for a human and a computer to sort and parse eh? it's trivial for humans to parse. Most of the world uses that format in day-to-day usage, albeit with some kind of separator of course. it's also absolutely trivial for a computer to sort and parse, of course. saying it's "unnecessarily" (to redirect the quotes) difficult, you may as well say decimal itself is unnecessarily difficult. just use day of year, 1-365. you're splitting hairs here that don't need to be split.