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