I think that Tom Rushworth gave some good advice in his earlier reply
<http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-July/160749.html>.

The original Date and Time in Squeak were defined in a way that
made sense for a single user system, and in that context attempting
to define a Date in terms of time zones probably would have been
confusing and needlessly complex. Nowadays, people face problems
such as yours in which they would like a Date to be defined in
a way that is meaningful across time spans and across time zones.

My point of view would be:

1) For most people, this just does not matter.
2) Changing the definition of Date to always refer to the date
   as seen in a UTC time zone is one of many possible solutions,
   but it would break the system for the common use case of a
   single user who wants to think of a Date as the "date for
   this point in time in the time zone that I am in".
3) Solving this problem correctly is difficult. Refer to the
   TimeZoneDatabase integration into Squeak Chronology for an
   an idea of how extensive the changes would be.
4) Solving the problem the easy way (e.g. with limited changes
   to a few classes) is a fool's errand. It will never be really
   right, and somebody will always be unhappy about the tradeoffs
   you made.

So ... refer to Tom's reply, I don't think I can suggest anything
better :)

HTH,
Dave

p.s. I have a strong suspicion that partially reimplementing
Squeak Chronology in terms of PointInTime, where PointInTime is
guaranteed to be monotonically increasing magnitude independent
of time zone, might yield very large performance benefits. The
reason is that things like Monticello spend a good deal of time
calculating and comparing time stamps, and a simplification of
the underlying calculations might speed this up considerably.
However, this would be a big project and I have not tried it,
so I'm afraid that my theory is pure speculation at this point.

On Thu, Jul 07, 2011 at 09:11:36PM -0500, Chris Muller wrote:
> I think of a DateAndTime as a Point-in-time, and a Date as an Interval in time.
> 
> I think an argument can be made that, in the context of talking about
> an Interval of time defined by the calendar (e.g., Date or Month), the
> interval could be considered from the _World's_ frame-of-reference:
> 
>      as the timespan that _starts_ at midnight UTC
>      and ends just before the next midnight UTC (of the next Date).
> 
> This is the actual period for which March 31st, 2011 (for sake of
> example), existed for "the world".  After that, there was no more
> March 31st for anyone.
> 
> If we would accept this view then we could all have a consistent (and
> correct) notion of the exact interval of time a Date spanned.  Besides
> that, applications which otherwise have no interest to be concerned
> about TimeZones can remain simple and elegant.
> 
> When we talk about Date, we are talking about a Timespan with that
> "resolution" of 1 day, therefore forcing involvement a the shift of
> hours is unnecessary and ambiguous.  For example, I have several
> data-feed that come in only with Date information (not timestamps).  I
> have absolutely no need for timestamp but I certainly can be bitten
> hard if I gather the data-feed from a different time-zone.  And this
> is a very hard bug to identify, because it just "silently changes your
> logic" rather than blowing up.
> 
> Let's please consider this.  Otherwise, please tell me a best-practice
> for my problem described above - I have data-streams coming in with
> simple Dates in them, and I need to compare those Dates to other Dates
> which might be instantiated in a different TimeZone..
> 
>   - Chris
> 
> 
> On Wed, Jul 6, 2011 at 7:29 AM, David T. Lewis <lewis at mail.msen.com> 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.
> >>
> >> 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
> >
> >
> >