Hacker News Reader

Comment by secure | Hacker News Reader

I think it would make the point much clearer if the author of that article would actually explain a use case for this (apparently incorrectly handled) syntax which I have never ever come in contact with :).

View on HN

1) It's in the standard. If you call a function iso8601 you better follow that standard. Or document where the function deviates from it.

2) Just because you didn't come in contact with ordinal dates doesn't mean others don't need it.

3) The article has a link to https://en.wikipedia.org/wiki/Ordinal_date. The wiki page doesn't have any specific use cases but just use your imagination.

Usecase is that there are various embedded/industrial/enterprise systems that return and expect dates in either of those two formats as part of their API. Either because they want to represent the idea of "month" or because they don't care about days and not about week days and months (Implementing whole calendar in random embedded/industrial system is unnecessary busywork that costs you not only effort but also code size)

Well the point is that they shouldn't call the method iso8601 if it doesn't implement the whole iso8601 standard

That's a bold statement. I don't think I've ever seen a program / library which implements any standard completely and without issues. It's not uncommon to see a list of things that are not done, incomplete, or just called out as wrong and rejected from the implementation.

It's not perfect, but no implementation will ever be imho.

Not implementing part of a standard is different from implementing it differently than the standard specifies.

YYYY-MM is year-month, not year-day365. It's not very reasonable to interpret yyyy-mm as year-day365 in a function called iso8601 when the standard says that's not how to interpret it.

Ever seen a method called "validateEmailAddress" or something similar? Take any given implementation of that and you can predict with almost certainty that it does not validate all possible valid email addresses (which also has a spec that even came along after the internet was conceived).

I think it's OK to be missing a few aspects of the standard. But in that case, it should still parse correctly and throw a "not supported" exception for unsupported features.

Parsing it incorrectly is bad news.

Reply on news.ycombinator.com