Quantcast

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

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Chris Muller-3
> 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
>
>
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Chris Muller-3
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.

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

We've made something wrong and we've made it slow in the process.
Apps that care about timezones will use DateAndTimes.  Apps that don't
shouldn't be punished.

I propose Date's, by default, be created with the UTC offset, NOT the
local offset.

 - Chris

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jon Hylands

I agree Chris. If I'm interested in anything time-related for a given date, I'll use DateAndTime or TimeStamp or whatever. Date objects should care about year and month and day, and nothing more.

Incidentally, the place I'm using Dates that is screwing me up so badly is as the key to a Dictionary, so of course the TZ offset makes it so the key lookup fails when you change TZ's.

- Jon


On Thu, Feb 2, 2012 at 11:25 AM, Chris Muller <[hidden email]> wrote:
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.

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

We've made something wrong and we've made it slow in the process.
Apps that care about timezones will use DateAndTimes.  Apps that don't
shouldn't be punished.

I propose Date's, by default, be created with the UTC offset, NOT the
local offset.

 - Chris




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Yanni Chiu
In reply to this post by Chris Muller-3
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.

So, i agree: remove timezone from Date.

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jon Hylands
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?

- Jon



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David T. Lewis
In reply to this post by Yanni Chiu
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.
 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David T. Lewis
In reply to this post by Jon Hylands
On Thu, Feb 02, 2012 at 03:45:14PM -0500, Jon Hylands wrote:

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

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Nicolas Cellier
In reply to this post by Chris Muller-3
2012/2/2 Chris Muller <[hidden email]>:

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

No problem with that, but the comment shall not tell it's same as asUTC.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jon Hylands
In reply to this post by David T. Lewis


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.

I think Date should be renamed to Day, and then a new class (with the old sematics of Date as it used to be) be implemented under Magnitude.

I wonder how many people/projects that kind of change would affect...

- Jon



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Chris Muller-3
In reply to this post by Nicolas Cellier
> No problem with that, but the comment shall not tell it's same as asUTC.

Yeah, I agree.  I'll fix that for a future commit.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David T. Lewis
In reply to this post by Jon Hylands
On Thu, Feb 02, 2012 at 06:20:05PM -0500, Jon Hylands wrote:

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

Ah, good. Thanks for checking.

>
> I think Date should be renamed to Day, and then a new class (with the old
> sematics of Date as it used to be) be implemented under Magnitude.

Sounds reasonable.

>
> I wonder how many people/projects that kind of change would affect...

It's hard to tell, although Chris is apparently using Date fairly
heavily, so if the change can be done without messing up his work
to badly, that would be a good sign :)

Dave


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Casey Ransberger-2
In reply to this post by David T. Lewis
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.
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Nicolas Cellier
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,
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.
>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Nicolas Cellier
2012/2/3 Nicolas Cellier <[hidden email]>:
> 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 <[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.
>>>
>>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David T. Lewis
In reply to this post by David T. Lewis
On Thu, Feb 02, 2012 at 04:01:18PM -0500, David T. Lewis wrote:
>
> 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.
>

Hi,

To follow up on my own question, the failing tests in TimeTransformTest
are due to an issue in my own unit tests, as opposed to something that
was changed in the Squeak image. Sorry for the noise.

I have not decided how to handle it this properly yet, but the failing
tests all involve calculated differences of 23 seconds, which happens to
be the number of leap seconds that have transpired since the Posix epoch.
My Linux computer is set to use time zone tables that ignore leap seconds,
and some of my unit tests are doing calculations with a time zone table
that does uses leap seconds, hence the 23 second difference. The problem
is exposed when I use primitiveUtcWithOffset to obtain seconds since the
epoch from the operating system, then compare that value with my calculated
value from the other time zone table (that calculation is based on Squeak
time, which originates from a seconds clock reported in local time rather
than UTC). The Cog VMs do not support primitiveUtcWithOffset, so I am able
to see the problem only when running on an interpreter VM.

I'll fix this in the TimeZoneDatabase package once I figure out the right
way to handle the issue. It is not an problem caused by any Squeak image
or VM.

Dave



Loading...