"Creates a new Date object by parsing from a string according to some typical ISO 8601 formats."
Not "all ISO 8601 formats," "some typical ISO 8601 formats." While supporting more formats is obviously desirable, the method never claimed to be a complete ISO 8601 implementation. It would be nicer if it were, but would also take more work and it appears that 100% spec support was neither prioritized nor promised.
I believe the second complaint is less justified. Asking a single class (Date) to support multiple granularities opens up a lot of semantic conundrums that have no obvious resolution. What should this return?
If one is truly month granularity and one is day granularity, then the two aren't directly comparable. It would make more sense to me to have the month granularity representation be a separate class altogether (YearMonth?) with easy and well-defined conversions between the two.
If you support only a subset of the standard, or if you extend the standard, that may still be OK (not without problems, but still OK in some situations).
This case seems like an outright violation, however. If the standard says that ####-## is a year-month date with month granularity, and you interpret it as an ordinal date, then that's a clear violation. It means that others communicating with you won't just get an error, they will get the wrong answer, which is much worse.
PS I did my undergrad thesis on Ruby; I love the language. But now that I have a job where people read my code more often than it's written, I understand why things like clear semantics matter.
And why method names should be precise since they lead developers to assume behavior. Didn't your english teacher tell you a poem's title means something? So do method names. "iso8601" implies some meaningful relationship to ISO 8601, but the only relationship here is that the coders of this method were thinking hard about ISO 8601 when they wrote it.
ISO 8601 is large standard and predates the internet (as we know it) and seems like an attempt of formalizing all the many different ways people expressed dates (on physical papers in addition to computer systems), and also some ways no-one would ever use.
I think you’ll find a lot of APIs (or formats) claiming to support an “ISO 8601 date” when in fact they mean a date of the form “YYYY-MM-DD” — it’s a common misunderstanding, but I think better that, than actually allowing the full range of dates allowed by the actual ISO 8601 standard :)
My God. The W3C actually made something simpler. Drastically simpler; simple enough to write down on one page. Mind you, it's just a note that someone else submitted, and the W3C hasn't formally discussed it, let alone blessed it -- but even so, it's heartening.
Oh sure, I know the full extent of the madness. At a previous job I was working with XML Schema durations to represent energy emissions data. It gives me bad memories.
The problem with making all dates into ranges is that there would be no total order. To effectively have a total order, you would need to say "give me the range of time at the smallest possible granularity", which is really just asking for a point in time. If the granularity becomes smaller later, it might break the application if you aren't careful. So, I don't think it's a good idea to give up on points in time.
However, I strongly agree that ranges of time are a very useful concept, and I spent a lot of time implementing Range Types[1] in postgresql for that reason. I think Ruby should have both ranges of time and points of time (and ideally work with the SQL counterparts seamlessly).
Does a point in time ever really exist? I think it's all ranges, just with smaller granularities, until you get into quantum mechanics. So, your point-in-time type is actually a range-with-granularity-X type, which should be able to inter-operate with range types of different granularities in a well-defined way.
I've recently done a lot of work using time ranges (a scheduling app) in C#, using the TimePeriod library available via NuGet. Very helpful library, but it would have been even better if DB2 (which I have to use quite often) supported a range type like you've implemented for PostgreSQL.
I agree, but that gets a little too philosophical. Does an integer exist? What about characters: is my "a" really the same as your "a"?
The way I see it, there are a lot of practical reasons to look at time as a total order for some things, even if ranges are available. Programming languages and databases should model reality, but only in the sense that it's relevant to what you are trying to do. If you are writing a scheduling app, then ranges of time are very important, and should be their own data type. If you just want to tell your customers when they bought some widget, a point in time makes more sense.
Of course an integer exists; it's a mathematical zero-dimensional point. Time is not a pure mathematical construct like that; it's continuous (at non-quantum scales, at least). Characters are integral, non-continuous values too... there's nothing between "a" and "b".
If you define the total order of a set of time ranges as an ordering on their beginnings, then you have the ordering you're talking about. If you compare time ranges that have different granularities the results might not make a ton of sense depending on what you're trying to do, but they'll be consistent. Eg: 2012 < 2012-05 < 2012-05-03 < 2012-05-03T15:00:00. Is the year 2012 "less than" May 3, 2012? Interpreted as a point in time, yes, but interpreted as time periods no, not really, because they overlap. But 2012 might be a perfectly valid value for when a customer bought some widget; if you ask them they may not remember the date any more specifically than that, and if you're deciding whether or not to process a warranty claim just knowing the year might be sufficient.
"If you define the total order of a set of time ranges as an ordering on their beginnings"
What is the data type of the beginning of a range of time, if not a point in time? I'm having trouble even defining ranges without points.
I'd be interested to hear your suggestions in more detail. There's a temporal data LinkedIn group that you are welcome to join (I haven't been as active lately, but I'll try to get back into it). It would be a better forum to discuss matters like this.
Basically, RFC3339 is ISO8601 cut down to the most straightforward implementation (YYYY-MM-DDTHH:MM:SS), without the "Ordinal Date" variant that is at issue here.
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 :).
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)
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.
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.
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).
So do tons of other libraries and PL standard libraries. jodatime in Java, moment.js, JS' Date object, python's datetime stdlib module, python-dateutil etc. ISO-8601 is actually quite a difficult standard to program for. 9 out of 10 times, these libraries either don't support just year, year-month, or both. 9 out of 10 times, when a datetime object is formatted to a string, you see inconsistencies about that dangling Z marker at the end.
Tom Morris is right, they all suck when it comes to ISO-8601 support.
Not only that, but ISO 8601 also allows you to just specify the year, but Date.iso8601("2012") raises an ArgumentError "invalid date". Nor does it support "week dates", Date.iso8601("2012-W01") raises an ArgumentError too.
I don't know the standard, but either Wikipedia is wrong or the Date implementation is sorely lacking.
It may well be lacking in completeness, but I bet it covers over 99% of actual real-world ISO8601 dates. When was the last time you ran across a "week date"?
Very common in Europe, where businesses often operate relative to weeks; we frequently use week numbers for that reason (an abomination in my opinion). Ruby has decent but not great support for ISO week numbers.
I've been reading the source code of one ISO 8601 implementation in JavaScript and writing my own in Java. Looks like I'll have to fix the Ruby one too.
Given that it's used by, oh, HTML and XML, not properly implementing ISO 8601 is really no big deal.</sarcasm>
Was it just me or was the wording in the article slightly confusing? The second paragraph changes from talking about the standard to talking about the ruby implementation with out saying so in either case and no transition.
If I understand correctly, the complaint is that: ISO 8601 defines ####-## to be a year and month only, and it should have the granularity of a month; but Ruby treats it as an ordinal date.
It seems like it could be said much more clearly with an example:
While we're on this subject, does anyone know of a decent C or C++ date-time library? Something like Joda Time. I know Boost has a couple of options but they look a bit less capable.
Replying to my own post, in case someone stumbles on this while searching: ICU. It's rather baroque, but seems to do the right thing. I recommend writing a C++11 wrapper for it (I might actually release this at some point in the future).
In any case if he wants to champion the change he will get more success discussing it over there. It's not that hard but yeah it's easier to moan over a blog post than actually fixing the issue.
I'm actually working with other data-folk trying to document ISO 8601 compliance across a wide range of date-time libraries and document it publicly, probably on the microformats.org wiki or W3C wiki.
Expect to see more of these headlines now Ruby 2.0.0 is out, as Rubyists start nudging users over by painting v 1.9 as defective. Good way to avoid the Python 3 and Perl 6 conundrums I suppose!
1. Date.iso8601 does not correctly parse some ISO 8601 formats like ordinal dates or month-only dates.
2. The Date class does not support year-only or year/month granularity.
In response to the first, the documentation for Date.iso8601 (http://ruby-doc.org/stdlib-1.9.3/libdoc/date/rdoc/Date.html#...) says:
"Creates a new Date object by parsing from a string according to some typical ISO 8601 formats."
Not "all ISO 8601 formats," "some typical ISO 8601 formats." While supporting more formats is obviously desirable, the method never claimed to be a complete ISO 8601 implementation. It would be nicer if it were, but would also take more work and it appears that 100% spec support was neither prioritized nor promised.
I believe the second complaint is less justified. Asking a single class (Date) to support multiple granularities opens up a lot of semantic conundrums that have no obvious resolution. What should this return?
If one is truly month granularity and one is day granularity, then the two aren't directly comparable. It would make more sense to me to have the month granularity representation be a separate class altogether (YearMonth?) with easy and well-defined conversions between the two.