> 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
>
>
>
>