2012/2/3 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> Chris, makeUTC already solved your both problems right?
> - it makes Date comparable, even when coming from DateAndTime of
> different time zone
> - it makes hash fast enough
>
> In this case I don't see the point of creating yet another class, or
> do I miss something ?
>
> And weather makeUTC should be the default or not, I don't really care,

Hem, whether I'm a bit obsessed with weather these days is obvious -
negative temperature in Nantes are unusual and the pipe bringing hot
water to my bathroom are frozen :(

Nicolas

> but if you make it the default, at least make a copy of the
> DateAndTime, otherwise DateAndTime>>asDate will modify the receiver.
>
> Nicolas
>
> 2012/2/3 Casey Ransberger <casey.obrien.r at gmail.com>:
>> Top post: What he said. Or maybe we move the timezone specific stuff down a notch in the hierarchy, and have a class above it that just does fast UTC, but please don't take it out. It's one of those wonderful things most systems don't have.
>>
>> +1 for Dave's argument. Besides, I can't get a date to save my life!
>>
>> On Feb 2, 2012, at 1:01 PM, "David T. Lewis" <lewis at mail.msen.com> wrote:
>>
>>> On Thu, Feb 02, 2012 at 02:50:56PM -0500, Yanni Chiu wrote:
>>>> On 02/02/12 11:25 AM, Chris Muller wrote:
>>>>>
>>>>> Best to strip all Dates (NOT DateAndTimes) of their timezone.
>>>>
>>>> IMHO, there are two different concepts getting mixed up.
>>>
>>> Correct.
>>>
>>>>
>>>> 1) There is a "date", which has a day, month and year (and calendar). If
>>>> you're modeling dates to be printed on a 12-month calendar that can be
>>>> used anywhere in the world, then this is the kind of date you want.
>>>>
>>>
>>> Yes, I think that was more or less the original implementation in earlier
>>> Squeak before Chronology was added.
>>>
>>>
>>>> 2) There is the 24hr period (sometimes 23hr or 25hr) which corresponds
>>>> to that "date". This 24hr period is timezone dependent. If you're making
>>>> a scheduling application, then this is the kind of date you need.
>>>
>>> Yes, and this is the meaning of "date" in more recent Squeak.
>>>
>>>>
>>>> So, i agree: remove timezone from Date.
>>>
>>> Date does not have a timezone. It has a start DateAndTime, which in
>>> turn has an offset from UTC. Neither Date nor DateAndTime has a timezone.
>>>
>>>>
>>>>> I propose Date's, by default, be created with the UTC offset, NOT the
>>>>> local offset.
>>>>
>>>> Disagree. The natural default for today, is the date in my local
>>>> timezone. Maybe #todayUTC should be introduced. Then why not add
>>>> #todayInTimezone: too. Hmm...timezones seem to be creeping back in.
>>>>
>>>
>>> +1
>>>
>>> And more generally, don't change it at all unless we can clearly
>>> state the (new?) meaning of "date" and write it down in a class
>>> comment for all to see and understand. A "date" may mean very
>>> different things in the context of different use cases, so if
>>> there is an interest in making something with a different meaning,
>>> it suggests that a different class should be invented. There is
>>> also an ANSI Smalltalk definition to keep in mind here.
>>>
>>> Dave
>>>
>>> p.s. I just ran the unit tests for TimeZoneDatabase and see new
>>> failures, but only when running on the standard interpreter. Did
>>> we change something in the image in a Cog-dependent way? I'll track
>>> it down as soon as I get some time but if someone can point me to
>>> the answer I'd appreciate it.
>>>
>>>
>>