2015-06-03 16:13 GMT-03:00 Sven Van Caekenberghe <[email protected]>: >> But is unnecesary heretic. Date is a "calendar date", not a point in >> time. "May 3rd" is the same "date" as "May 3rd" whether you are in >> Sydney or Houston.
>> ps: ISO 8601 doesn't mention anything about "date" timezones. In fact >> the word "timezone" implies time, not date. > I understand your POV, but you should have read what I originally wrote: the > Date that we have now is more than an abstract date, it is an object that can > answer to certain messages, like tell you when it starts, ends, whether it > contains certain points in time. In order to do that, you have to know in > which timezone to interpret it in. It is more than a Date because it is a Timespan, which behaves as an interval (*). But it is "so more" than the expected date, that breaks the expectation of what a Date is for me. > Look, I am not defending the current design, I just try to explain. No need to excuse, I totally understand it. I'm just ranting a little. > And May 3rd, interpreted as a concrete period of time, [from,to], is *NOT* > the same in Sydney and Houston. (*) If you consider a date as an interval then it's right, but if you consider it an index of a discrete sequence, then it's wrong to treat it as an interval. In a sequence of integer numbers, you have 1, 2, 3... n, and there is no interval in between. If you store the "date of birth" it doesn't matter if you were born in Sidney, you wont get presents until is that date in Houston :P In my opinion what is wrong is that aDate is-an Interval. But that's how it is. So I'll "deal with it". :) Best regards. -- Esteban.
