If
'3/31/2011' asDate
is executed in two different time-zones, it will produce two Dates which are not equal (#=).
The view is that a Date is a "Timespan with duration of 1 day," and the implementation is strict-enough to respect that that duration occurs at different times for everyone around the world.
Date>>#< (the less-than selector) also respects the time-zone, the time-zone which occurs further west is > the one created in the east since it started after.
But when Dates from different TimeZones are intermixed into a persistent object-model, it circumvents an elegant simplicity of comparing dates. March 31st coincides within 24 hours for all of us, and so that's "close enough" for many applications to want to consider the object, [March 24th, 2011], as equal to all of the other [March 24th, 2011] Dates regardless of which TimeZone they occurred in.
It is absolutely correct that DateAndTimes respect Time-Zones as they do. What do you think about Dates?
On Tue, Jul 05, 2011 at 11:38:13PM -0500, Chris Muller wrote:
If
'3/31/2011' asDate
is executed in two different time-zones, it will produce two Dates which are not equal (#=).
The view is that a Date is a "Timespan with duration of 1 day," and the implementation is strict-enough to respect that that duration occurs at different times for everyone around the world.
Date>>#< (the less-than selector) also respects the time-zone, the time-zone which occurs further west is > the one created in the east since it started after.
But when Dates from different TimeZones are intermixed into a persistent object-model, it circumvents an elegant simplicity of comparing dates. March 31st coincides within 24 hours for all of us, and so that's "close enough" for many applications to want to consider the object, [March 24th, 2011], as equal to all of the other [March 24th, 2011] Dates regardless of which TimeZone they occurred in.
It is absolutely correct that DateAndTimes respect Time-Zones as they do. What do you think about Dates?
I think of a Date as a view on a PointInTime, and from that perspective the answer to your question would be yes, a Date should represent a date relative to some time zone.
Having said that, I would note that it is difficult to do this "correctly" with the representation of Date and DateAndTime in Squeak, largely for historical reasons.
If you are interested in storing date information in a persistent object-model, such that you are storing values that refer to different points in time in different time zones, then there is no really "correct" way to do it. Consider for example the problem of calculating elapsed seconds between two point in time in two different time zones in the case where a daylight savings transition has occurred in one of the two time zones. Or the problem of defining a date in terms of duration if a daylight savings transition has occurred during that time span.
Please try loading TimeZoneDatabase from SqueakMap (or from http://www.squeaksource.com/TimeZoneDatabase), and have a look at the included documentation and unit tests. This will give you a better feel for the inherent problems, and I'd certainly be interested in any feedback you might have.
As an aside, the TimeZoneDatabase package is something I wrote long ago, and that I expected to be very popular when folks started doing server applications like Seaside. On the other hand, I wrote OSProcess to entertain myself and expected that no one would pay any attention to it. So now OSProcess is quite popular, and TimeZoneDatabase is universally ignored. Go figure ;-)
Dave
On 11/07/06 05:29, David T. Lewis wrote:
On Tue, Jul 05, 2011 at 11:38:13PM -0500, Chris Muller wrote:
If
'3/31/2011' asDate
is executed in two different time-zones, it will produce two Dates which are not equal (#=).
The view is that a Date is a "Timespan with duration of 1 day," and the implementation is strict-enough to respect that that duration occurs at different times for everyone around the world.
[snip]
I faced a similar issue with a transaction based application I developed, and eventually decided that the persistent values I would store would all be a time in seconds UTC, and that I would convert to local time only for display and would convert local time input dates to UTC as soon as possible. It doesn't really solve the problem of '3/31/2011' since that's one of interpretation, but it suggests that you try to split the problem into:
1) what to store for persistence, 2) what to use for display/input, 3) how and when to convert between them.
I didn't need the concept that "a day is the same day anywhere" for my application, which made problem 3 simple. You might need to store something more complicated, like the UTC time or duration together with conversion method information (e.g. shift by TZ offset, don't shift, ...).
For example, to deal with "a day is a day anywhere", you would store the UTC date and the info that it should have the TZ offset added in before display. Such days would compare as UTC times, but would display as a proper local day.
You would then have at least a chance to decide on sensible comparison algorithms because they could look at the conversion info as well as the actual UTC time.
Regards,
On Wed, Jul 06, 2011 at 08:27:19AM -0700, Tom Rushworth wrote:
On 11/07/06 05:29, David T. Lewis wrote:
On Tue, Jul 05, 2011 at 11:38:13PM -0500, Chris Muller wrote:
If
'3/31/2011' asDate
is executed in two different time-zones, it will produce two Dates which are not equal (#=).
The view is that a Date is a "Timespan with duration of 1 day," and the implementation is strict-enough to respect that that duration occurs at different times for everyone around the world.
[snip]
I faced a similar issue with a transaction based application I developed, and eventually decided that the persistent values I would store would all be a time in seconds UTC, and that I would convert to local time only for display and would convert local time input dates to UTC as soon as possible. It doesn't really solve the problem of '3/31/2011' since that's one of interpretation, but it suggests that you try to split the problem into:
- what to store for persistence,
- what to use for display/input,
- how and when to convert between them.
I didn't need the concept that "a day is the same day anywhere" for my application, which made problem 3 simple. You might need to store something more complicated, like the UTC time or duration together with conversion method information (e.g. shift by TZ offset, don't shift, ...).
For example, to deal with "a day is a day anywhere", you would store the UTC date and the info that it should have the TZ offset added in before display. Such days would compare as UTC times, but would display as a proper local day.
You would then have at least a chance to decide on sensible comparison algorithms because they could look at the conversion info as well as the actual UTC time.
Regards,
-- Tom Rushworth
FWIW, this sounds like very good advice to me.
Dave
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
David T. Lewis -
Tom Rushworth