How to have a fast and usable Date? (was: new Bug in Locale)

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

>> 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 <[hidden email]> 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
>>
>>
>>
>>
>

> 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 <[hidden email]>:
>>> 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 <[hidden email]> 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
>>>
>>>
>>>
>>>
>>

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

> On Thu, Feb 2, 2012 at 2:50 PM, Yanni Chiu <[hidden email]> 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.
> >
> > 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.
> >
> > 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.
> >
>
> I assume that's what a Timespan is for, the superclass of Date.
>
> Actually, it looks to me like we're missing a class. Perhaps we should have
> a "Day", which represents that 24 hour period, since we have similar
> classes for Week, Month, and Year, which are also all Timespans. That would
> allow Date to represent #1 above.
>
> Thoughts?

> On Thu, Feb 2, 2012 at 2:30 AM, Nicolas Cellier
> <[hidden email]> wrote:
>> 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).
>
> Not good enough, because having TZ-specific dates in any system of
> consequence is a scourge of molasses.
>
> Best to strip all Dates (NOT DateAndTimes) of their timezone.
>
>> 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
>
> makeUTC was intended solely to purge the molasses for apps that are
> not interested in TZ's.
>

> On Thu, Feb 2, 2012 at 4:05 PM, David T. Lewis <[hidden email]> wrote:
>
>
> > Sounds right to me. I can only add that whichever class most closely
> > resembles
> > the ANSI Smalltalk definition of Date should be called "Date", and the
> > other
> > thing can be called "Day".
>
>
> Dave,
>
> On quick look it appears the ANSI standard only specifies DateAndTime, and
> not Date at all.

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

> 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" <[hidden email]> 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.
>>
>>
>

> 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 <[hidden email]>:
>> 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" <[hidden email]> 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.
>>>
>>>
>>