On 11/07/07 19:11, 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.

I don't really follow this argument.  I'm not saying it's wrong, just
that I'm not understanding what it is you're trying to say.
> 
> 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

If your requirement is just for dates corresponding to days, why not
just convert '3/31/11' to an integer 20110331?  They would compare and
sort just fine, and you could skip the whole TZ question.  You might
make use of Date to do part of the conversion, but then you extract the
year, month and day and throw the rest away.
> 
> 
> 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
>>
>>
>>
> 
> 


-- 
Tom Rushworth