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