Without checking the code, this sounds weird.

There is a local date and a UTC date which can be different.
The date when created should indeed take the local time zone into account IMO.
Thus, Date today and DateAndTime now should answer the same Date.

However, I do not well see why a Date once created has to point to the
Time zone.
Two Date created in different time zones should be equal IMHO.

If we have to use time and time zone in order to compare dates, this
is going to be germane.
For example, this case is interesting:

01/01/2012 17h (UTC + 8h)
01/01/2012 20h (UTC)

If we convert the two DateAndTime in UTC, these are the same dates, if
we convert the two DateAndTime in (UTC+8h) these are different dates.
So, what would it mean to compare Date?

Nicolas

2012/2/2 Chris Muller <asqueaker at gmail.com>:
>> When you execute "Date today", it produces a Date object with DateAndTime
>> localTimeZone's offset
>
> Jon, I'm very curious your thoughts about this -- that a Date needs to
> know its timezone.
>
> By Date today being a special, localized instance of today, it means
> February 1st, 2012 created in other timezones or maybe even since a
> daylight-savings cutover, are now not equal.
>
> Worse, the hashing cost:
>
>        |dt| dt:=Date today.
>        [ dt hash ] bench    '108,000 per second.'
>
>
>        |dt| dt:=Date today makeUTC.
>        [ dt hash ] bench    '1,360,000 per second.'
>
> Squeak users all over the world except in UTC are using slow Dates.
> You can bet they probably don't expect them to be time-zone sensitive.
>  That would be what a DateAndTime would be for.
>
> I have more than one of my own applications which use Dates, but none
> of them are interested in the timezone of the midnight those dates
> "started" at.
>
> But, due to that hashing cost, I'm forced to sprinkle the code with
> #makeUTC calls (just checked:  I'm up to 13 senders now!) just so that
> regular comparing and arithmetic operations will behave correctly.
>
> There are plenty of use-cases where applications employ Dates do not
> want want them to be TZ-specific.  But is there any use case anywhere
> where timezone-specific Dates would be more useful and/or more
> efficient than just a DateAndTime?
>
> I tried to make this case once before,
>
>    http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-July/160571.html
>
> but no one had any concrete context of their own to be able to relate.
>  But you just did, and I wondered whether you had any thoughts..
>
>
>
> On Tue, Jan 31, 2012 at 10:12 AM, Jon Hylands <jon at huv.com> wrote:
>>
>> Hi everyone,
>>
>> I've ported some of my code into Squeak 4.3 (was running in 4.2 before), and
>> ran into a weird issue comparing Date objects.
>>
>> When you execute "Date today", it produces a Date object with DateAndTime
>> localTimeZone's offset, which is set upon image startup to be Locale >>
>> offsetLocalToUTC, which in turn calls Locale >> primTimezone.
>>
>> On a 4.2 image, on both my XP and Windows 7 machines, that primitive returns
>> -300 (minutes), which is -5 hours, which is correct (since I live in SW
>> Ontario, Canada, which is EST).
>>
>> On a 4.3 image, with or without updates, that method returns -240, which is
>> -4, which is clearly wrong at this point in time.
>>
>> - Jon
>>
>>
>>
>>
>