Hacker News Reader

Comment by UI_at_80x24 | Hacker News Reader

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.

View on HN

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

That should be 1925dec19 (or 19dec1925 if you like little-endian), otherwise year vs day is ambigous.

Not between XX32 and XX00 as per last century.

I think the past two decades have made it clear that that's a unacceptably brittle system.

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

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

Props to you for citing ISO 8601. Most folks don’t care :(

See also RFC 3339, which seems to be a stricter dialect of ISO 8601. https://stackoverflow.com/questions/522251/whats-the-differe...

Or as I like to call it, xkcd 1179 time

It 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

[2] https://www.iso.org/standard/70908.html

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

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

I'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?

Reply on news.ycombinator.com