Hi Sean,
On Tue, Aug 26, 2014 at 04:21:09PM -0700, Sean P. DeNigris wrote:
David T. Lewis wrote
the two main responsibilities of DateAndTime. One is to represent time as a magnitude (for duration calculation, etc). The other is to display time in the frame of reference of a local time zone. It is not at all clear to me that those two responsibilies belong in the same class.
There is definitely something fishy with the combination. Consider Pharo's Date, which retroactively applies the current timezone to dates. This is bad because e.g.: '7/10/2014' asDate "evaluated the day before DST" ~= '7/10/2014' asDate "evaluated the day after DST"
I created an issue, which has been sitting on the bug tracker. Here's an excerpt from the discussion (https://pharo.fogbugz.com/default.asp?12147#BugEvent.90264):
I see that a particular location could reasonably be implied in a Date, e.g. if we're saying that a treaty was signed on such and such a date, we mean at the place where it was signed... it may have already been the next day in another time zone.
Now, what is beyond doubt, is that the timezone that would be implied is the timezone of the date itself, not an artifact of when the instance was created. In my example, I create '11/12/2013' asDate, and it assumes my timezone. Since it's the summer in NY, that means -4 offset. Now, I evaluate '11/12/2013' asDate again in December. Again it implies my timezone, the offset of which has changed to -5! So now '11/12/2013' asDate (in NY) ~= '11/12/2013' asDate (in NY). Even though the offset of the date in question, which depends only on whether DST was in effect on 11/12/2013, has not changed.
So the current behavior of two equal dates being considered not-equal is as jarring as your counter example of two non-equal dates (different timezone) being considered equal.
The term "Date" can mean a lot of different things in different contexts, so I think this is very much a matter of agreeing on definitions. As an example, I work in the automotive manufacturing industry, where the term "production date" has a very specific meaning that has very little to do with time zones or specific points in time. But in general, most common usage of the term "date" are meant to imply local time.
There doesn't seem to be an easy, direct solution because I'm assuming we don't have a primitive for "the offset at this location on X date in the past".
You are exactly right. As far as I am aware, there is no straightforward way to use the C runtime libraries to obtain the offset for an arbitrary time_t in the context of some specified time zone. So this is not something that can be easily supported in a primitive. On the other hand, the current offset in the current time zone is easily obtained, and that is now provided by the the #primitiveUtcWithOffset primitive.
Fortunately, if you have access to the time zone rules, it is quite easy to do these sorts of calculation in the image. This would typically be done using the publicly available Olson time zone tables. Several implementations have been done in Smalltalk, including the one that I did at http://www.squeaksource.com/TimeZoneDatabase.
So the next best thing might be a PlatonicDate (obviously a name-in-progress :)) that represents the abstract idea of a Date without regard to location, and then an object to connect a particular place/offset to that concept (but the second one would have the same problem as we currently have).
I like that approach. Interestingly, if you look at an old version of Squeak (ST-80), the Date class was implemented as you describe. It had no notion of location or time zone. Maybe there is a better way now that we could represent your PlatonicDate (aka ST-80?) such that it would collaborate with time zones and DateAndTime, but possibly would not be tied to them in implementation.
Dave