> On 03 Jun 2015, at 20:10, Esteban A. Maringolo <[email protected]> wrote:
> 
> 2015-06-03 12:05 GMT-03:00 Sven Van Caekenberghe <[email protected]>:
>>> On 03 Jun 2015, at 16:57, Ben Coman <[email protected]> wrote:
>>> I've observed several of date/time discussions that I didn't really
>>> follow all the details, but my first thought here is that Date, Time,
>>> and DateAndTime are three separate concepts.  Shouldn't timezones only
>>> affect comparing dates if you are calculating the hours between dates?
>>> Adding the concept of "starting at a specific moment in time" would
>>> seem to turn a Date into a DateAndTime, which is the point where
>>> timezones should have an impact.
> 
> +1.
> 
> Time is time. No matter "where" it happens.
> 
> 
>>> For example, if you are reading a date "dd/mm/yyyy" from some database
>>> field, what timezone do you assign?
> 
>> That is indeed the (original) problem.
> 
> Exactly.
> 
>> But even dd/mm/yyyy in some random DB or somewhere on the internet implies a 
>> timezone, else it does not make (enough/total) sense.
> 
> IMO, it doesn't imply a timezone.
> 
>> Again, your date today is not equal to mine, at some point in time we are in 
>> different days, it is that simple.
> 
> 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.
> 
> And for those "edge" cases where your calendar date is different from
> mine we have DateAndTime, and so does the database with the Timestamp
> format.
> 
> It is the first time I have to deal with an implementation of Date
> that includes a timezone offset in it. Funny is I never had to deal
> with this before.
> 
> Regards!
> 
> Esteban A. Maringolo
> 
> 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.

Look, I am not defending the current design, I just try to explain.

And May 3rd, interpreted as a concrete period of time, [from,to], is *NOT* the 
same in Sydney and Houston.


Reply via email to