Hacker News new | past | comments | ask | show | jobs | submit login
Unicode date formats, YYYY? (boredzo.org)
30 points by ingve on Oct 24, 2015 | hide | past | favorite | 12 comments



If you're curious about ISO week dates, there is a nice Wikipedia article on it that explains what is going on a little more clearly.

https://en.wikipedia.org/wiki/ISO_week_date


WTF, who designed that format? That's like having a gun where the muzzle points backwards if you forget a step assembling it.


If you use printf-like function without precise understanding semantics, you're asking for trouble. No amount of careful design is going to change that.


Does this apply to every DSL?


Not necessarily, because a robust DSL can enforce its semantics. When your "DSL" is just a string to the parent language, not so much. (Though modern compilers can emit warnings about obvious printf issues like incorrect types.)


Funny you should mention that - the Canadians used a battle rifle in both World Wars that effectively had just such a defect - the "Ross Rifle".

From Wikipedia:

> The bolt could also be disassembled for routine cleaning and inadvertently reassembled in a manner that would fail to lock but still allow a round to be fired, leading to serious injury or death of the operator as the bolt flew back into his face

https://en.wikipedia.org/wiki/Ross_rifle


Two things:

* As rdancer mentions, you must always fully understand printf-style format options before you use them. To do otherwise invites disaster.

* What would you have chosen for the four-digit-calendar-year format specifier and the four-digit-week-of-year format specifier?

Edit: Notice also that you can add more "y" or "Y" characters to get greater precision, so the existing format specifiers already solve the Y10K problem.


I agree with everything you said and don't think this format is bad at all, but regarding your "Y10K problem" note, I actually prefer PHP date format, that is "Y/y" instead of "yyyy/yy".

First of, I'm sure you need year far more often than "week year", so the less intuitive encoding for the latter is acceptable and I have to admit that confusing letter case is pretty easy when the result is identical for most of the time (so simple "run it, see if it works" won't help, and that's exactly how everybody does programming).

Second, I don't imagine I'll ever want to display last three symbols of the year instead of the full year, and I most of the time don't want to get "0476" instead of "476" — and if I do, I'm actually OK with post-processing for these special occasions. The only thing I actually want is full year format (whatever long it is) or, rarely, short (2-letter) year format (which I actually think is stupid and never use it except somebody specifically asks me to). So while I'm absolutely clear with what "Y/y" does, I have no idea what 'yyy' would do for 4-digit long year or what 'yyyy' would do for 3 or 5 digit long year for that matter.


I would have changed the year and day capitalization, so that YYYY-MM-DD produces a standard ISO date.

Although, to be fair, strftime() also requires inconsistent capitalization for ISO dates.


Time measuring units are a mess, and there's no way out of it. (At least while we want them to reflect astronomical events.)

Do not complain that people who were handed a mess of a problem to solve got a bad API out of it. That's how things go.


Even as someone who uses and is fairly happy with ISO week numbers, I think you're quite right.

The problem isn't the ISO 8601 calendar - smart people have thought about these things, and it's probably the best decision to let 2015-W53 contain days in 2016 (gaining in return a contiguous calendar of weeks each with seven days). But 'week numbers year' is obscure enough to deserve a noticeably different format letter.


Unicode date formats can be used in PHP via `ext/intl`, the ICU wrapper library;

    $ php -r 'date_default_timezone_set("Etc/UTC"); $x = new IntlDateFormatter("en_GB", 0, 0); $x->setPattern("yyyy"); echo $x->format(time());'




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: