41–50 of 50 posts
Well done you found an issue. The next step is to report it and if possible submit a patch: http://bugs.ruby-lang.org/projects/ruby/wiki/HowtoReport
This isn't exactly a bug; it's an API-design disagreement.
Why not just fill a bug report?
Earlier quoted context omitted.
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…
"Does a point in time ever really exist?" 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…
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.
Earlier quoted context omitted.
"Does a point in time ever really exist?" 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…
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 compar…
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.
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!
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…
I wonder how Perl's DateTime::Format::ISO8601 [1] holds up... [1] https://metacpan.org/module/DateTime::Format::ISO8601
$ re.pl
>> use aliased 'DateTime::Format::ISO8601';
>> ISO8601->parse_datetime("2012-012");
2012-01-12T00:00:00
>> ISO8601->parse_datetime("2012-366");
2012-12-31T00:00:00
>> ISO8601->parse_datetime("2012-12");
2012-12-01T00:00:00
>> ISO8601->parse_datetime("2012");
2012-01-01T00:00:00
1 - https://metacpan.org/module/Date::ISO8601
Earlier quoted context omitted.
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.
A lot of public parks in London are open at different times during summer and winter.
Here's an example I added personally, the churchyard of St Anne's Church in Soho. http://www.openstreetmap.org/browse/way/40879988
"week 1-13 Mo-Su 10:00-16:00; week 14-43 10:00-18:00; week 44-52 10:00-16:00"
Earlier quoted context omitted.
This isn't exactly a bug; it's an API-design disagreement.
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.
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.