I'm now inspecting implementation, and indeed, Date is an interval
taking start time into account.
So you can still compare the Date printString... (quite slow).

I read that makeUTC is like asUTC but it's not.
The former just erase the offset, the later does remove the offset from time.

t := DateAndTime year: 2012 month: 2 day: 1 hour: 9 minute: 8 second:
23 offset: 2 hours.
self deny: t asUTC = t copy makeUTC

I also notice that the offset used to create a DateAndTime is NOT
taken into account when extracting the Date...
The Date is always extracted with local time zone which is ... weird.

DateAndTime>>midnight
	"Answer a DateAndTime starting at midnight local time"

	^self class basicNew
		setJdn: jdn
		seconds: 0
		nano: 0
		offset: self class localOffset

Since midnight is used in Date creation, I now have the answer how
germane it is to compare the dates of two DateAndTime.

d1 := DateAndTime starting: (DateAndTime year: 2012 month: 2 day: 1
hour: 15 minute: 0 second: 0 offset: 8 hours).
d2 := DateAndTime starting: (DateAndTime year: 2012 month: 2 day: 1
hour: 20 minute: 0 second: 0 offset: 0 hours).
self guess: d1 asDate = d2 asDate answer: 'it depends on your local time zone'.

Well, why not, but good luck to write the SUnitTests, you have to
modify a global (time zone) to make them work reliably ;)

Nicolas

2012/2/2 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> 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
>>>
>>>
>>>
>>>
>>