Bug Fix and a Question concerning DateAndTime in Kernal-Chronology

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug Fix and a Question concerning DateAndTime in Kernal-Chronology

JohnReed Maffeo
For the first time in many years I am de-lurking to submit a change to Squeak. My report and suggested fix is at http://bugs.squeak.org/view.php?id=7693. The change is a modification of the behavior of fromString: to interpret $Z as a valid time zone designator.

I am only posting this to the list for confirmation that I did the right thing using Mantis, and to ask a question about the name/behavior of the method asUTC in class DateAndTime.

The name asUTC makes me think that the parameter provided will be converted to the equivalent value at the zero time zone. Instead the method just converts the time zone offset to zero.

I am not sure what the intention revealing method name should be for the current behavior, but since asUTC and asLocal are already taken, I would like to suggest a set of methods to convert a given DateAndTime toUTC and toLocal. I think I could code them up with the appropriate tests and would welcome the challenge if there is any support for the suggestion.

Regards,

JohnReed

Reply | Threaded
Open this post in threaded view
|

Re: Bug Fix and a Question concerning DateAndTime in Kernal-Chronology

David T. Lewis
On Mon, Jul 09, 2012 at 10:04:11PM -0400, JohnReed Maffeo wrote:
> For the first time in many years I am de-lurking to submit a change to Squeak. My report and suggested fix is at http://bugs.squeak.org/view.php?id=7693. The change is a modification of the behavior of fromString: to interpret $Z as a valid time zone designator.
>

Hi JohnReed,
Thanks for de-lurking!

> I am only posting this to the list for confirmation that I did the right thing using Mantis, and to ask a question about the name/behavior of the method asUTC in class DateAndTime.
>

I moved your changes into Squeak trunk and marked the Mantis issue as resolved. So I guess you must have done the right thing :)
 
> The name asUTC makes me think that the parameter provided will be converted to the equivalent value at the zero time zone. Instead the method just converts the time zone offset to zero.
>
> I am not sure what the intention revealing method name should be for the current behavior, but since asUTC and asLocal are already taken, I would like to suggest a set of methods to convert a given DateAndTime toUTC and toLocal. I think I could code them up with the appropriate tests and would welcome the challenge if there is any support for the suggestion.
>

I think that is a reasonable and safe way to handle it.

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: Bug Fix and a Question concerning DateAndTime in Kernal-Chronology

Colin Putney-3
On Mon, Jul 9, 2012 at 7:54 PM, David T. Lewis <[hidden email]> wrote:
>> I am only posting this to the list for confirmation that I did the right thing using Mantis, and to ask a question about the name/behavior of the method asUTC in class DateAndTime.
>>
>
> I moved your changes into Squeak trunk and marked the Mantis issue as resolved. So I guess you must have done the right thing :)

Yup. Thanks especially for posting here to let us know about the fix.
It could have gone unnoticed in mantis for a while.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: Bug Fix and a Question concerning DateAndTime in Kernal-Chronology

Bert Freudenberg
In reply to this post by JohnReed Maffeo

On 2012-07-10, at 04:04, JohnReed Maffeo wrote:

> For the first time in many years I am de-lurking to submit a change to Squeak. My report and suggested fix is at http://bugs.squeak.org/view.php?id=7693. The change is a modification of the behavior of fromString: to interpret $Z as a valid time zone designator.
>
> I am only posting this to the list for confirmation that I did the right thing using Mantis, and to ask a question about the name/behavior of the method asUTC in class DateAndTime.
>
> The name asUTC makes me think that the parameter provided will be converted to the equivalent value at the zero time zone. Instead the method just converts the time zone offset to zero.
>
> I am not sure what the intention revealing method name should be for the current behavior, but since asUTC and asLocal are already taken, I would like to suggest a set of methods to convert a given DateAndTime toUTC and toLocal. I think I could code them up with the appropriate tests and would welcome the challenge if there is any support for the suggestion.
>
> Regards,
>
> JohnReed

asUTC and asLocal are actually defined in the ANSI Smalltalk standard:

asLocal
        Answer a <DateAndTime> that represents the same UTC time as the receiver but in the local time specified by the implementation.

asUTC
        Answer a <DateAndTime> that represents the same absolute time as the receiver but in the local time UTC. The exact meaning of UTC local time is specified by the implementation. The UTC local time must use the Gregorian calendar. <DateAndTimes> representing UTC times prior to the adoption of the Gregorian calendar must use the retrospective astronomical Gregorian calendar. It is an invariant that
        <DateAndTime> asUTC offset = Duration zero.

If they currently do not do what they're supposed to do we should fix that.

(This also makes clear that using the Julian calendar for early dates is not allowed, so my proposed change is no good)

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Bug Fix and a Question concerning DateAndTime in Kernal-Chronology

JohnReed Maffeo
In reply to this post by JohnReed Maffeo
> ----- Original Message -----
> From: Bert Freudenberg
> Sent: 07/10/12 12:32 PM
> To: The general-purpose Squeak developers list
> Subject: Re: [squeak-dev] Bug Fix and a Question concerning DateAndTime in Kernal-Chronology
>
> On 2012-07-10, at 04:04, JohnReed Maffeo wrote:
>
> > For the first time in many years I am de-lurking to submit a change to Squeak. My report and suggested fix is at http://bugs.squeak.org/view.php?id=7693. The change is a modification of the behavior of fromString: to interpret $Z as a valid time zone designator.
> >
> > I am only posting this to the list for confirmation that I did the right thing using Mantis, and to ask a question about the name/behavior of the method asUTC in class DateAndTime.
> >
> > The name asUTC makes me think that the parameter provided will be converted to the equivalent value at the zero time zone. Instead the method just converts the time zone offset to zero.
> >
> > I am not sure what the intention revealing method name should be for the current behavior, but since asUTC and asLocal are already taken, I would like to suggest a set of methods to convert a given DateAndTime toUTC and toLocal. I think I could code them up with the appropriate tests and would welcome the challenge if there is any support for the suggestion.
> >
> > Regards,
> >
> > JohnReed
>
> asUTC and asLocal are actually defined in the ANSI Smalltalk standard:
>
> asLocal
> Answer a <DateAndTime> that represents the same UTC time as the receiver but in the local time specified by the implementation.
>
> asUTC
> Answer a <DateAndTime> that represents the same absolute time as the receiver but in the local time UTC. The exact meaning of UTC local time is specified by the implementation. The UTC local time must use the Gregorian calendar. <DateAndTimes> representing UTC times prior to the adoption of the Gregorian calendar must use the retrospective astronomical Gregorian calendar. It is an invariant that
> <DateAndTime> asUTC offset = Duration zero.
>
> If they currently do not do what they're supposed to do we should fix that.
>
> (This also makes clear that using the Julian calendar for early dates is not allowed, so my proposed change is no good)
>
> - Bert -

My observation is that the current implementation does not conform to the ANSI Smalltalk standard as Bert presented it. I do not see any unit tests for toUTC and toLocal in TestRunner; I am starting to write them and see that there are some interesting challenges in developing the them. The first challenge that I am going to address is the fact a definitive, universal test cannot rely on the value of the local offset.

I am planning to  open an item in Mantis once I have a basic test complete.

JohnReed

Reply | Threaded
Open this post in threaded view
|

Re: Bug Fix and a Question concerning DateAndTime in Kernal-Chronology

JohnReed Maffeo
In reply to this post by JohnReed Maffeo
> ----- Original Message -----
> From: JohnReed Maffeo
> Sent: 07/12/12 08:59 AM
> To: [hidden email]
> Subject: Re: [squeak-dev] Bug Fix and a Question concerning DateAndTime in Kernal-Chronology
>
> > ----- Original Message -----
> > From: Bert Freudenberg
> > Sent: 07/10/12 12:32 PM
> > To: The general-purpose Squeak developers list
> > Subject: Re: [squeak-dev] Bug Fix and a Question concerning DateAndTime in Kernal-Chronology
> >--- snip
> > asUTC and asLocal are actually defined in the ANSI Smalltalk standard:
> >
> > asLocal
> > Answer a <DateAndTime> that represents the same UTC time as the receiver but in the local time specified by the implementation.
> >
> > asUTC
> > Answer a <DateAndTime> that represents the same absolute time as the receiver but in the local time UTC. The exact meaning of UTC local time is specified by the implementation. The UTC local time must use the Gregorian calendar. <DateAndTimes> representing UTC times prior to the adoption of the Gregorian calendar must use the retrospective astronomical Gregorian calendar. It is an invariant that
> > <DateAndTime> asUTC offset = Duration zero.
> >
> > If they currently do not do what they're supposed to do we should fix that.
> >
> > (This also makes clear that using the Julian calendar for early dates is not allowed, so my proposed change is no good)
> >
> > - Bert -
>
> My observation is that the current implementation does not conform to the ANSI Smalltalk standard as Bert presented it. I do not see any unit tests for toUTC and toLocal in TestRunner; I am starting to write them and see that there are some interesting challenges in developing the them. The first challenge that I am going to address is the fact a definitive, universal test cannot rely on the value of the local offset.
>
> I am planning to  open an item in Mantis once I have a basic test complete.
>
> JohnReed

When I opened a fresh 4.3 image to start writine tests, I discovered that the current implementation of asLocal and asUTC are working as expected. I now believe that somehow, the image that I was working in when I first reported a possible bug was corrupted somehow. It had been open on my computer for many days and I may have fat fingered something. I am still going to try and code up tests for asLocal and asUTC because I like the challenge.
JohnReed

Reply | Threaded
Open this post in threaded view
|

Re: Bug Fix and a Question concerning DateAndTime in Kernal-Chronology

Levente Uzonyi-2
On Wed, 18 Jul 2012, JohnReed Maffeo wrote:

>> ----- Original Message -----
>> From: JohnReed Maffeo
>> Sent: 07/12/12 08:59 AM
>> To: [hidden email]
>> Subject: Re: [squeak-dev] Bug Fix and a Question concerning DateAndTime in Kernal-Chronology
>>
>>> ----- Original Message -----
>>> From: Bert Freudenberg
>>> Sent: 07/10/12 12:32 PM
>>> To: The general-purpose Squeak developers list
>>> Subject: Re: [squeak-dev] Bug Fix and a Question concerning DateAndTime in Kernal-Chronology
>>> --- snip
>>> asUTC and asLocal are actually defined in the ANSI Smalltalk standard:
>>>
>>> asLocal
>>> Answer a <DateAndTime> that represents the same UTC time as the receiver but in the local time specified by the implementation.
>>>
>>> asUTC
>>> Answer a <DateAndTime> that represents the same absolute time as the receiver but in the local time UTC. The exact meaning of UTC local time is specified by the implementation. The UTC local time must use the Gregorian calendar. <DateAndTimes> representing UTC times prior to the adoption of the Gregorian calendar must use the retrospective astronomical Gregorian calendar. It is an invariant that
>>> <DateAndTime> asUTC offset = Duration zero.
>>>
>>> If they currently do not do what they're supposed to do we should fix that.
>>>
>>> (This also makes clear that using the Julian calendar for early dates is not allowed, so my proposed change is no good)
>>>
>>> - Bert -
>>
>> My observation is that the current implementation does not conform to the ANSI Smalltalk standard as Bert presented it. I do not see any unit tests for toUTC and toLocal in TestRunner; I am starting to write them and see that there are some interesting challenges in developing the them. The first challenge that I am going to address is the fact a definitive, universal test cannot rely on the value of the local offset.
>>
>> I am planning to  open an item in Mantis once I have a basic test complete.
>>
>> JohnReed
>
> When I opened a fresh 4.3 image to start writine tests, I discovered that the current implementation of asLocal and asUTC are working as expected. I now believe that somehow, the image that I was working in when I first reported a possible bug was corrupted somehow. It had been open on my computer for many days and I may have fat fingered something. I am still going to try and code up tests for asLocal and asUTC because I like the challenge.
> JohnReed
Are you sure you used #asUTC and not #makeUTC?


Levente

>
>