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:
> 
> 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,
> 
> -- 
> Tom Rushworth

FWIW, this sounds like very good advice to me.

Dave