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 |
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 |
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 |
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 - |
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 |
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 |
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 Levente > > |
Free forum by Nabble | Edit this page |