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 -