On 18.03.2016, at 18:29, Chris Muller <asqueaker at gmail.com> wrote:
> 
>> | a b |
>> DateAndTime automaticTimezone: true.
>> a := DateAndTime now asUTC.
>> DateAndTime automaticTimezone: false.
>> DateAndTime localOffset: 5 hours.
>> b := DateAndTime now asUTC.
>> {a. b}
>> ==> {2016-03-18T15:50:21.731797+00:00 . 2016-03-18T11:50:21.731797001+00:00}
> 
> Interesting. 

I just fixed this one. By setting the time zone (localOffset) now the local time appears to jump. UTC is continuous, as it should be.

A side effect is that the clock in our tool bar now shows that adjusted local time.

To ensure the millisecondClock is continuous, it now follows UTC. 

All tests are still green so I hope it’s good.

And Max’s tests might work again, too, without manual preference fiddling.

>  Do you know whether this bug affects any API besides #now?

I think the comments in DateAndTime>>offset: and utcOffset: could use updating. They both claim to return an “equivalent” but they’re not:

x := DateAndTime now.
x = (x offset: 0)
==> false

x = (x utcOffset: 0)
==> true

Since “utcOffset:" appears to do the right thing I’d actually prefer it to the “nowAtOffset:” you just introduced. E.g. to get the current time in LA you could simply use

DateAndTime now utcOffset: -7 hours

No need for a new message. Arguably this is what “offset:” should do, and it would if the implementation was utc-based (as is David’s) rather than local-time based.

- Bert -



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4207 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160319/339d57a9/smime.bin