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.
