Timezone offset in Date, why?
Locked
Timezone offset in Date, why?
 
|
I'm debugging the PostgresV3 driver for GLORP, and among other test
failures, there is a kind that particularly bugs me: two identical dates do not match, the reason? The internal "start" of aDate (Timespan) is a DateAndTime, and as such has a timezone offset. Is this conceptually right? Esteban A. Maringolo |
Re: Timezone offset in Date, why?
|
|
I'm not sure how I would handle that,
but I would take a look at Chalten/Aconcagua on how they do that. |
Re: Timezone offset in Date, why?
|
|
In reply to this post by Esteban A. Maringolo
> On 03 Jun 2015, at 04:20, Esteban A. Maringolo <[hidden email]> wrote: > > I'm debugging the PostgresV3 driver for GLORP, and among other test > failures, there is a kind that particularly bugs me: two identical > dates do not match, the reason? The internal "start" of aDate > (Timespan) is a DateAndTime, and as such has a timezone offset. > > Is this conceptually right? > > Esteban A. Maringolo Yes, it is bit annoying and weird, but it all does make sense as well. The concept of a date cannot be seen independent from a timezone (day transitions are different for you than for me, new year starts at different moments depending on where you live). Defining a Date as the timespan of one day starting at a specific moment in time is correct. One thing you could try is to make the starting time UTC, a bit like Date today translateToUTC. DateAndTime now asUTC asDate. But I am not sure how much of your problems this would solve. Sven |
Re: Timezone offset in Date, why?
|
Administrator
|
In reply to this post by Esteban A. Maringolo
Welcome to hell ;) 12147 Date>>#= fooled by daylight savings time https://pharo.fogbugz.com/default.asp?12147 testEqualDaylightSavings "If I create a date, say in New York, during Daylight Savings Time (hereafter DST), and then create the same date, also in NY but outside of DTS, they should be equal" | dateDuringDST sameDateOutsideDST | dateDuringDST := Date starting: (january23rd2004 start translateTo: -4 hours). sameDateOutsideDST := Date starting: (january23rd2004 start translateTo: -5 hours). self assert: dateDuringDST equals: sameDateOutsideDST.
Cheers,
Sean |
|
|
In reply to this post by Sven Van Caekenberghe-2
On Wed, Jun 3, 2015 at 8:36 PM, Sven Van Caekenberghe <[hidden email]> wrote:
> >> On 03 Jun 2015, at 04:20, Esteban A. Maringolo <[hidden email]> wrote: >> >> I'm debugging the PostgresV3 driver for GLORP, and among other test >> failures, there is a kind that particularly bugs me: two identical >> dates do not match, the reason? The internal "start" of aDate >> (Timespan) is a DateAndTime, and as such has a timezone offset. >> >> Is this conceptually right? >> >> Esteban A. Maringolo > > Yes, it is bit annoying and weird, but it all does make sense as well. > The concept of a date cannot be seen independent from a timezone (day transitions are different for you than for me, new year starts at different moments depending on where you live). > Defining a Date as the timespan of one day starting at a specific moment in time is correct. 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. For example, if you are reading a date "dd/mm/yyyy" from some database field, what timezone do you assign? cheers -ben > One thing you could try is to make the starting time UTC, a bit like > > Date today translateToUTC. > > DateAndTime now asUTC asDate. > > But I am not sure how much of your problems this would solve. > > Sven > > |
Re: Timezone offset in Date, why?
|
|
> On 03 Jun 2015, at 16:57, Ben Coman <[hidden email]> wrote: > > On Wed, Jun 3, 2015 at 8:36 PM, Sven Van Caekenberghe <[hidden email]> wrote: >> >>> On 03 Jun 2015, at 04:20, Esteban A. Maringolo <[hidden email]> wrote: >>> >>> I'm debugging the PostgresV3 driver for GLORP, and among other test >>> failures, there is a kind that particularly bugs me: two identical >>> dates do not match, the reason? The internal "start" of aDate >>> (Timespan) is a DateAndTime, and as such has a timezone offset. >>> >>> Is this conceptually right? >>> >>> Esteban A. Maringolo >> >> Yes, it is bit annoying and weird, but it all does make sense as well. > >> The concept of a date cannot be seen independent from a timezone (day transitions are different for you than for me, new year starts at different moments depending on where you live). >> Defining a Date as the timespan of one day starting at a specific moment in time is correct. > > 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. Currently: Date is a Timespan of 24h starting at a specific, universally unique point in time (a DateAndTime). You can ask it things like when did you begin, end, do you contain t. Other, more abstract notions of a Date are possible, of course, but that is not what we have. > 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. 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. Again, your date today is not equal to mine, at some point in time we are in different days, it is that simple. > cheers -ben > >> One thing you could try is to make the starting time UTC, a bit like >> >> Date today translateToUTC. >> >> DateAndTime now asUTC asDate. >> >> But I am not sure how much of your problems this would solve. >> >> Sven |
Re: Timezone offset in Date, why?
|
|
I do this: localTimeZoneToRestore := DateAndTime localTimeZone. DateAndTime localTimeZone: (TimeZone abbreviated: 'UTC'). "Do stuff" time := DateAndTime midnight. DateAndTime localTimeZone: TimeZone default. Phil
|
Re: Timezone offset in Date, why?
|
|
In reply to this post by Sven Van Caekenberghe-2
2015-06-03 12:05 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
>> On 03 Jun 2015, at 16:57, Ben Coman <[hidden email]> 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. |
Re: Timezone offset in Date, why?
|
|
2015-06-03 15:10 GMT-03:00 Esteban A. Maringolo <[hidden email]>:
> Time is time. No matter "where" it happens. Looking at Postgres documentation [1] about Date/Time types, they have a time with timezone and time without it. The default is without. There is no "date with timezone" type. I refer Postgres datatypes because I find them to have a good criteria based on a huge user base and because is what raised the issue I'm dealing with now. Regards! -- Esteban. [1] http://www.postgresql.org/docs/devel/static/datatype-datetime.html |
Re: Timezone offset in Date, why?
|
|
On 03-06-15 20:15, Esteban A. Maringolo wrote:
> I refer Postgres datatypes because I find them to have a good criteria > based on a huge user base and because is what raised the issue I'm > dealing with now. SQL databases are well-known to have ignored the standards for dealing with times and dates for decades to make it difficult to switch to a competitor. For performance reasons you'll probably often want to map to smallint value objects. Stephan |
Re: Timezone offset in Date, why?
|
|
In reply to this post by Esteban A. Maringolo
> On 03 Jun 2015, at 20:10, Esteban A. Maringolo <[hidden email]> wrote: > > 2015-06-03 12:05 GMT-03:00 Sven Van Caekenberghe <[hidden email]>: >>> On 03 Jun 2015, at 16:57, Ben Coman <[hidden email]> 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. |
Re: Timezone offset in Date, why?
|
|
In reply to this post by Esteban A. Maringolo
> Time is time. No matter "where" it happens.
The theory of relativity disagrees |
Re: Timezone offset in Date, why?
|
|
In reply to this post by Sven Van Caekenberghe-2
2015-06-03 16:13 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
>> 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. |
Re: Timezone offset in Date, why?
|
|
In reply to this post by Esteban A. Maringolo
On 03/06/15 20:15, Esteban A. Maringolo wrote:
> I refer Postgres datatypes because I find them to have a good criteria > based on a huge user base and because is what raised the issue I'm > dealing with now. I like the work by Richard Snodgrass. His "Developing Time-Oriented Database Applications in SQL" is available here: http://www.cs.arizona.edu/~rts/publications.html Stephan |
Re: Timezone offset in Date, why?
|
|
In reply to this post by Stephan Eggermont-3
2015-06-03 15:36 GMT-03:00 Stephan Eggermont <[hidden email]>:
> On 03-06-15 20:15, Esteban A. Maringolo wrote: >> >> I refer Postgres datatypes because I find them to have a good criteria >> based on a huge user base and because is what raised the issue I'm >> dealing with now. > > > SQL databases are well-known to have ignored the standards for > dealing with times and dates for decades to make it difficult to > switch to a competitor. Sorry, but never heard of this intentional ignorance, particularly coming from PostgreSQL. Nonetheless, I had to deal with stupid issues in Oracle 7i-11g, but that's another story. Regarding standards, I mentioned the ISO 8601 where I haven't seen a case where a plain date comes with a timezone offset. > For performance reasons you'll probably often want to map to smallint value objects. And lose the date abstraction the database provides me with? It is up to the database how to optimize the store of its datatypes. Regards! Esteban A. Maringolo |
Re: Timezone offset in Date, why?
|
|
In reply to this post by Stephan Eggermont-3
2015-06-03 17:20 GMT-03:00 Stephan Eggermont <[hidden email]>:
> On 03/06/15 20:15, Esteban A. Maringolo wrote: >> >> I refer Postgres datatypes because I find them to have a good criteria >> based on a huge user base and because is what raised the issue I'm >> dealing with now. > I like the work by Richard Snodgrass. > His "Developing Time-Oriented Database Applications in SQL" is > available here: > http://www.cs.arizona.edu/~rts/publications.html Thank you! Looks very interesting. Esteban |
Re: Timezone offset in Date, why?
|
|
In reply to this post by Esteban A. Maringolo
On 03/06/15 22:21, Esteban A. Maringolo wrote:
> 2015-06-03 15:36 GMT-03:00 Stephan Eggermont <[hidden email]>: >> For performance reasons you'll probably often want to map to smallint value objects. > > And lose the date abstraction the database provides me with? It is up > to the database how to optimize the store of its datatypes. Uhm, no on the smalltalk side. A DateAndTime is large and slow. Stephan |
Re: Timezone offset in Date, why?
|
|
2015-06-03 17:57 GMT-03:00 Stephan Eggermont <[hidden email]>:
> On 03/06/15 22:21, Esteban A. Maringolo wrote: >> >> 2015-06-03 15:36 GMT-03:00 Stephan Eggermont <[hidden email]>: >>> For performance reasons you'll probably often want to map to smallint >>> value objects. >> And lose the date abstraction the database provides me with? It is up >> to the database how to optimize the store of its datatypes. > Uhm, no on the smalltalk side. A DateAndTime is large and slow. A Date is larger in Pharo, it has two objects: aDateAndTime and aDuration. And one the rules that I value the most in the long time is the "Rule of Representation: Fold knowledge into data so program logic can be stupid an robust". Regarding the "Time oriented Databases" book you recommended, it makes a clear distinction about instants and intervals in a whole chapter (Chapter 3), and in all the chapter and implementations of SQL-92 (superseeded by SQL-2011) I couldn't find a single use case nor mention of a Date with a timezone. I think this discussion is depleted, Pharo Date implementation is as it is. Every suggestion is a workaround to a design choice made a lot of time ago. Thanks for your time. Esteban A. Maringolo |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |