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
I'm not sure how I would handle that, but I would take a look at Chalten/Aconcagua on how they do that. â
On 03 Jun 2015, at 04:20, Esteban A. Maringolo <emaringolo@gmail.com> 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
On Wed, Jun 3, 2015 at 8:36 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 03 Jun 2015, at 04:20, Esteban A. Maringolo <emaringolo@gmail.com> 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
On 03 Jun 2015, at 16:57, Ben Coman <btc@openinworld.com> wrote:
On Wed, Jun 3, 2015 at 8:36 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 03 Jun 2015, at 04:20, Esteban A. Maringolo <emaringolo@gmail.com> 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
Le 3 juin 2015 17:05, "Sven Van Caekenberghe" <sven@stfx.eu> a écrit :
On 03 Jun 2015, at 16:57, Ben Coman <btc@openinworld.com> wrote:
On Wed, Jun 3, 2015 at 8:36 PM, Sven Van Caekenberghe <sven@stfx.eu>
wrote:
On 03 Jun 2015, at 04:20, Esteban A. Maringolo <emaringolo@gmail.com>
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.
I do this: localTimeZoneToRestore := DateAndTime localTimeZone. DateAndTime localTimeZone: (TimeZone abbreviated: 'UTC'). "Do stuff" time := DateAndTime midnight. DateAndTime localTimeZone: TimeZone default. Phil
Sven
2015-06-03 12:05 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 03 Jun 2015, at 16:57, Ben Coman <btc@openinworld.com> 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.
2015-06-03 15:10 GMT-03:00 Esteban A. Maringolo <emaringolo@gmail.com>:
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
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
2015-06-03 15:36 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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
On 03/06/15 22:21, Esteban A. Maringolo wrote:
2015-06-03 15:36 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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
2015-06-03 17:57 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
On 03/06/15 22:21, Esteban A. Maringolo wrote:
2015-06-03 15:36 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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
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
2015-06-03 17:20 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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
On 03 Jun 2015, at 20:10, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2015-06-03 12:05 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 03 Jun 2015, at 16:57, Ben Coman <btc@openinworld.com> 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.
2015-06-03 16:13 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
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.
Esteban A. Maringolo wrote
two identical dates do not match, the reason? The internal "start" of aDate (Timespan) is a DateAndTime, and as such has a timezone offset.
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 -- View this message in context: http://forum.world.st/Timezone-offset-in-Date-why-tp4830101p4830217.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
participants (7)
-
Ben Coman -
Esteban A. Maringolo -
phil＠highoctane.be -
Sean P. DeNigris -
Sergio Fedi -
Stephan Eggermont -
Sven Van Caekenberghe