Smalltalk › Squeak › Squeak - Dev

Status of date problem

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

26 messages Options

Max Leske

Status of date problem

Hi,

The Fuel builds for trunk are still failing because our tests with dates and timezones fail due to the recently diagnosed problem with date and time in the image (the topic was “trunk thinks it’s tomorrow”).

I haven’t seen any activity on that front in the last couple of days. What is the status? When can I expect this to be fixed? Or was it already fixed?

Cheers,
Max

Bert Freudenberg

Re: Status of date problem

Are you using the latest trunk image? It should be fixed.

- Bert -

> On 12.03.2016, at 09:45, Max Leske <[hidden email]> wrote:
>
> Hi,
>
> The Fuel builds for trunk are still failing because our tests with dates and timezones fail due to the recently diagnosed problem with date and time in the image (the topic was “trunk thinks it’s tomorrow”).
>
> I haven’t seen any activity on that front in the last couple of days. What is the status? When can I expect this to be fixed? Or was it already fixed?
>
> Cheers,
> Max

smime.p7s (8K) Download Attachment

Max Leske

Re: Status of date problem

In reply to this post by Max Leske

Thanks Bert, I’ll check but I’m pretty sure I am. I’ll take a look at the test cases in question too to make sure its not the tests.

On 13 Mar 2016, at 23:24, [hidden email] wrote:

Are you using the latest trunk image? It should be fixed.

- Bert -

On 12.03.2016, at 09:45, Max Leske <[hidden email]> wrote:

Hi,

The Fuel builds for trunk are still failing because our tests with dates and timezones fail due to the recently diagnosed problem with date and time in the image (the topic was “trunk thinks it’s tomorrow”).

I haven’t seen any activity on that front in the last couple of days. What is the status? When can I expect this to be fixed? Or was it already fixed?

Cheers,
Max

Bert Freudenberg

Re: Status of date problem

All the Chronology tests in trunk are green right now. I’d be curious to know what’s failing in Fuel.

- Bert -

On 16.03.2016, at 08:21, Max Leske <[hidden email]> wrote:

Thanks Bert, I’ll check but I’m pretty sure I am. I’ll take a look at the test cases in question too to make sure its not the tests.

On 13 Mar 2016, at 23:24, [hidden email] wrote:

Are you using the latest trunk image? It should be fixed.

- Bert -

On 12.03.2016, at 09:45, Max Leske <[hidden email]> wrote:

Hi,

The Fuel builds for trunk are still failing because our tests with dates and timezones fail due to the recently diagnosed problem with date and time in the image (the topic was “trunk thinks it’s tomorrow”).

I haven’t seen any activity on that front in the last couple of days. What is the status? When can I expect this to be fixed? Or was it already fixed?

Cheers,
Max

smime.p7s (5K) Download Attachment

Max Leske

Re: Status of date problem

In reply to this post by Max Leske

I found the problem. DateAndTime gained “automatic timezone”. So when I change the timezone in my tests it doesn’t have an effect unless I disable that.

You should think about disabling automatic timezone when the timezone has been changed manually. When I change the timezone I expect that change to be effective.

Cheers,

Max

On 16 Mar 2016, at 08:21, Max Leske <[hidden email]> wrote:

Thanks Bert, I’ll check but I’m pretty sure I am. I’ll take a look at the test cases in question too to make sure its not the tests.

On 13 Mar 2016, at 23:24, [hidden email] wrote:

Are you using the latest trunk image? It should be fixed.

- Bert -

On 12.03.2016, at 09:45, Max Leske <[hidden email]> wrote:

Hi,

The Fuel builds for trunk are still failing because our tests with dates and timezones fail due to the recently diagnosed problem with date and time in the image (the topic was “trunk thinks it’s tomorrow”).

I haven’t seen any activity on that front in the last couple of days. What is the status? When can I expect this to be fixed? Or was it already fixed?

Cheers,
Max

Bert Freudenberg

Re: Status of date problem

There is a preference for that (DateAndTime automaticTimezone: false).

Interesting idea to automatically disable the pref when setting the timezone manually … Although I’m not sure that should happen silently. Maybe a warning should pop up telling you that you probably want to disable the pref?

- Bert -

On 18.03.2016, at 15:26, Max Leske <[hidden email]> wrote:

I found the problem. DateAndTime gained “automatic timezone”. So when I change the timezone in my tests it doesn’t have an effect unless I disable that.

You should think about disabling automatic timezone when the timezone has been changed manually. When I change the timezone I expect that change to be effective.

Cheers,
Max

On 16 Mar 2016, at 08:21, Max Leske <[hidden email]> wrote:

Thanks Bert, I’ll check but I’m pretty sure I am. I’ll take a look at the test cases in question too to make sure its not the tests.

On 13 Mar 2016, at 23:24, [hidden email] wrote:

Are you using the latest trunk image? It should be fixed.

- Bert -

On 12.03.2016, at 09:45, Max Leske <[hidden email]> wrote:

Hi,

The Fuel builds for trunk are still failing because our tests with dates and timezones fail due to the recently diagnosed problem with date and time in the image (the topic was “trunk thinks it’s tomorrow”).

I haven’t seen any activity on that front in the last couple of days. What is the status? When can I expect this to be fixed? Or was it already fixed?

Cheers,
Max

smime.p7s (5K) Download Attachment

Chris Muller-3

Re: Status of date problem

> Interesting idea to automatically disable the pref when setting the timezone
> manually …

+1. I totally agree with Max.

Although I’m not sure that should happen silently. Maybe a
> warning should pop up telling you that you probably want to disable the
> pref?

-1. The user setting their timzone already implies their intent to do
so, a warning to confirm that intent would be superfluous and annoying
and disruptive to configuration tools.

Bert Freudenberg

Re: Status of date problem

In reply to this post by Bert Freudenberg

Or even better: setting the timezone should modify local time, not UTC. I guess that’s one of the motivations for Dave’s re-implementation.

If that were the case, then the clock in the tool bar would reflect the time in a different time zone, and people would eventually notice. No need for a warning. Hmm, I like that!

- Bert -

On 18.03.2016, at 16:12, Bert Freudenberg <[hidden email]> wrote:

There is a preference for that (DateAndTime automaticTimezone: false).

Interesting idea to automatically disable the pref when setting the timezone manually … Although I’m not sure that should happen silently. Maybe a warning should pop up telling you that you probably want to disable the pref?

- Bert -

On 18.03.2016, at 15:26, Max Leske <[hidden email]> wrote:

I found the problem. DateAndTime gained “automatic timezone”. So when I change the timezone in my tests it doesn’t have an effect unless I disable that.

You should think about disabling automatic timezone when the timezone has been changed manually. When I change the timezone I expect that change to be effective.

Cheers,
Max

On 16 Mar 2016, at 08:21, Max Leske <[hidden email]> wrote:

Thanks Bert, I’ll check but I’m pretty sure I am. I’ll take a look at the test cases in question too to make sure its not the tests.

On 13 Mar 2016, at 23:24, [hidden email] wrote:

Are you using the latest trunk image? It should be fixed.

- Bert -

On 12.03.2016, at 09:45, Max Leske <[hidden email]> wrote:

Hi,

The Fuel builds for trunk are still failing because our tests with dates and timezones fail due to the recently diagnosed problem with date and time in the image (the topic was “trunk thinks it’s tomorrow”).

I haven’t seen any activity on that front in the last couple of days. What is the status? When can I expect this to be fixed? Or was it already fixed?

Cheers,
Max

smime.p7s (5K) Download Attachment

Bert Freudenberg

Re: Status of date problem

In reply to this post by Chris Muller-3

On 18.03.2016, at 16:30, Chris Muller <[hidden email]> wrote:
>
>> Interesting idea to automatically disable the pref when setting the timezone
>> manually …
>
> +1. I totally agree with Max.

Yep. Right now there is no way to distinguish between automatic and manual setting, however.

> Although I’m not sure that should happen silently. Maybe a
>> warning should pop up telling you that you probably want to disable the
>> pref?
>
> -1. The user setting their timzone already implies their intent to do
> so, a warning to confirm that intent would be superfluous and annoying
> and disruptive to configuration tools.

The warning obviously would be displayed only if you had not disabled the setting, so the manual setting would have no effect.

But I agree, needless warnings are bad. See my other message for a better idea.

- Bert -

smime.p7s (5K) Download Attachment

Eliot Miranda-2

Re: Status of date problem

In reply to this post by Bert Freudenberg

On Mar 18, 2016, at 8:32 AM, Bert Freudenberg <[hidden email]> wrote:

Or even better: setting the timezone should modify local time, not UTC. I guess that’s one of the motivations for Dave’s re-implementation.

?!?! UTC should /never/ be changeable. One can alter one's conputer's clock to simulate computing in a different age, but UTC is supposed to be UTC and is entirely independent of time zone.

If that were the case, then the clock in the tool bar would reflect the time in a different time zone, and people would eventually notice. No need for a warning. Hmm, I like that!

And indeed the title bar clock could include the time zone abbreviation.

- Bert -

On 18.03.2016, at 16:12, Bert Freudenberg <[hidden email]> wrote:

There is a preference for that (DateAndTime automaticTimezone: false).

Interesting idea to automatically disable the pref when setting the timezone manually … Although I’m not sure that should happen silently. Maybe a warning should pop up telling you that you probably want to disable the pref?

- Bert -

On 18.03.2016, at 15:26, Max Leske <[hidden email]> wrote:

I found the problem. DateAndTime gained “automatic timezone”. So when I change the timezone in my tests it doesn’t have an effect unless I disable that.

You should think about disabling automatic timezone when the timezone has been changed manually. When I change the timezone I expect that change to be effective.

Cheers,
Max

On 16 Mar 2016, at 08:21, Max Leske <[hidden email]> wrote:

Thanks Bert, I’ll check but I’m pretty sure I am. I’ll take a look at the test cases in question too to make sure its not the tests.

On 13 Mar 2016, at 23:24, [hidden email] wrote:

Are you using the latest trunk image? It should be fixed.

- Bert -

On 12.03.2016, at 09:45, Max Leske <[hidden email]> wrote:

Hi,

The Fuel builds for trunk are still failing because our tests with dates and timezones fail due to the recently diagnosed problem with date and time in the image (the topic was “trunk thinks it’s tomorrow”).

I haven’t seen any activity on that front in the last couple of days. What is the status? When can I expect this to be fixed? Or was it already fixed?

Cheers,
Max

Bert Freudenberg

Re: Status of date problem

On 18.03.2016, at 16:46, Eliot Miranda <[hidden email]> wrote:

On Mar 18, 2016, at 8:32 AM, Bert Freudenberg <[hidden email]> wrote:

Or even better: setting the timezone should modify local time, not UTC. I guess that’s one of the motivations for Dave’s re-implementation.

?!?! UTC should /never/ be changeable. One can alter one's conputer's clock to simulate computing in a different age, but UTC is supposed to be UTC and is entirely independent of time zone.

Agreed. But right now DateAndTime still stores local time:

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

Which makes no sense. We should fix that, and I’m pretty sure it is fixed in David’s version.

If that were the case, then the clock in the tool bar would reflect the time in a different time zone, and people would eventually notice. No need for a warning. Hmm, I like that!

And indeed the title bar clock could include the time zone abbreviation.

We don’t know the abbrev … but showing the “wrong” time should be good enough.

- Bert -

- Bert -

On 18.03.2016, at 16:12, Bert Freudenberg <[hidden email]> wrote:

There is a preference for that (DateAndTime automaticTimezone: false).

Interesting idea to automatically disable the pref when setting the timezone manually … Although I’m not sure that should happen silently. Maybe a warning should pop up telling you that you probably want to disable the pref?

- Bert -

On 18.03.2016, at 15:26, Max Leske <[hidden email]> wrote:

I found the problem. DateAndTime gained “automatic timezone”. So when I change the timezone in my tests it doesn’t have an effect unless I disable that.

You should think about disabling automatic timezone when the timezone has been changed manually. When I change the timezone I expect that change to be effective.

Cheers,
Max

On 16 Mar 2016, at 08:21, Max Leske <[hidden email]> wrote:

Thanks Bert, I’ll check but I’m pretty sure I am. I’ll take a look at the test cases in question too to make sure its not the tests.

On 13 Mar 2016, at 23:24, [hidden email] wrote:

Are you using the latest trunk image? It should be fixed.

- Bert -

On 12.03.2016, at 09:45, Max Leske <[hidden email]> wrote:

Hi,

The Fuel builds for trunk are still failing because our tests with dates and timezones fail due to the recently diagnosed problem with date and time in the image (the topic was “trunk thinks it’s tomorrow”).

I haven’t seen any activity on that front in the last couple of days. What is the status? When can I expect this to be fixed? Or was it already fixed?

Cheers,
Max

smime.p7s (5K) Download Attachment

Eliot Miranda-2

Re: Status of date problem

On Mar 18, 2016, at 8:53 AM, Bert Freudenberg <[hidden email]> wrote:

On 18.03.2016, at 16:46, Eliot Miranda <[hidden email]> wrote:

On Mar 18, 2016, at 8:32 AM, Bert Freudenberg <[hidden email]> wrote:

Or even better: setting the timezone should modify local time, not UTC. I guess that’s one of the motivations for Dave’s re-implementation.

?!?! UTC should /never/ be changeable. One can alter one's conputer's clock to simulate computing in a different age, but UTC is supposed to be UTC and is entirely independent of time zone.

Agreed. But right now DateAndTime still stores local time:

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

Which makes no sense. We should fix that, and I’m pretty sure it is fixed in David’s version.

Phew :-)

If that were the case, then the clock in the tool bar would reflect the time in a different time zone, and people would eventually notice. No need for a warning. Hmm, I like that!

And indeed the title bar clock could include the time zone abbreviation.

We don’t know the abbrev … but showing the “wrong” time should be good enough.

I really should add a getenv: prim. Absurd that one has to load OSProcess (or use NativeBoost) just to get at environment variables.

- Bert -

- Bert -

On 18.03.2016, at 16:12, Bert Freudenberg <[hidden email]> wrote:

There is a preference for that (DateAndTime automaticTimezone: false).

Interesting idea to automatically disable the pref when setting the timezone manually … Although I’m not sure that should happen silently. Maybe a warning should pop up telling you that you probably want to disable the pref?

- Bert -

On 18.03.2016, at 15:26, Max Leske <[hidden email]> wrote:

I found the problem. DateAndTime gained “automatic timezone”. So when I change the timezone in my tests it doesn’t have an effect unless I disable that.

You should think about disabling automatic timezone when the timezone has been changed manually. When I change the timezone I expect that change to be effective.

Cheers,
Max

On 16 Mar 2016, at 08:21, Max Leske <[hidden email]> wrote:

Thanks Bert, I’ll check but I’m pretty sure I am. I’ll take a look at the test cases in question too to make sure its not the tests.

On 13 Mar 2016, at 23:24, [hidden email] wrote:

Are you using the latest trunk image? It should be fixed.

- Bert -

On 12.03.2016, at 09:45, Max Leske <[hidden email]> wrote:

Hi,

The Fuel builds for trunk are still failing because our tests with dates and timezones fail due to the recently diagnosed problem with date and time in the image (the topic was “trunk thinks it’s tomorrow”).

I haven’t seen any activity on that front in the last couple of days. What is the status? When can I expect this to be fixed? Or was it already fixed?

Cheers,
Max

Chris Muller-3

Re: Status of date problem

In reply to this post by Bert Freudenberg

> | 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. Do you know whether this bug affects any API besides #now?

David T. Lewis

Re: Status of date problem

In reply to this post by Eliot Miranda-2

On Fri, Mar 18, 2016 at 09:01:34AM -0700, Eliot Miranda wrote:

>
> > On Mar 18, 2016, at 8:53 AM, Bert Freudenberg <[hidden email]> wrote:
> >
> >> On 18.03.2016, at 16:46, Eliot Miranda <[hidden email]> wrote:
> >>
> >>> On Mar 18, 2016, at 8:32 AM, Bert Freudenberg <[hidden email]> wrote:
> >>>
> >>> Or even better: setting the timezone should modify local time, not UTC. I guess that???s one of the motivations for Dave???s re-implementation.
> >>
> >> ?!?! UTC should /never/ be changeable. One can alter one's conputer's clock to simulate computing in a different age, but UTC is supposed to be UTC and is entirely independent of time zone.
> >
> > Agreed. But right now DateAndTime still stores local time:
> >
> > | 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}
> >
> > Which makes no sense. We should fix that, and I???m pretty sure it is fixed in David???s version.
>
> Phew :-)
>

Sure, that one is fixed. But the more important point is to be able
to see and understand problems like this more easily by looking at the
DateAndTime instances directly in an inspector, see attached.

I was inspired by my earlier experiences (long ago now) trying to make
sense of Olson time zone tables in Squeak. Trying to figure out what was
supposed to be local time versus UTC, and which features were actually
bugs, was enough to make my head spin. I eventually came to the conclusion
that my own stupidity was only a part of the problem, and that there was
no real need for for things to be quite as confusing as they seemed to be.

Dave

DateAndTimeInExplorer.png (28K) Download Attachment

Bert Freudenberg

Re: Status of date problem

In reply to this post by Chris Muller-3

On 18.03.2016, at 18:29, Chris Muller <[hidden email]> 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 -

smime.p7s (5K) Download Attachment

David T. Lewis

Re: Status of date problem

On Sat, Mar 19, 2016 at 12:30:19AM +0100, Bert Freudenberg wrote:

> On 18.03.2016, at 18:29, Chris Muller <[hidden email]> 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.
>

I am not entirely sure what #utcOffset: should do. Presumably it should affect
UTC offset but not magnitude. Here is what I wrote in the method comment a
couple of years ago:

DateAndTime>>>utcOffset: anOffset

"Answer a <DateAndTime> equivalent to the receiver but offset from UTC by anOffset"

self flag: #FIXME. "check the definition of this and of #offset:"
^self utcMicroseconds: utcMicroseconds offset: anOffset asDuration asSeconds

So based on that #flag comment, my expectation was that #offset: should answer
a new instance with the same magnitude and a different time zone offset. That
still seems right to me.

Dave

Chris Muller-3

Re: Status of date problem

In reply to this post by Bert Freudenberg

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

I wish to keep #nowWithOffset:. DateAndTime's are "value" objects --
like Points and Fractions. I never want to write code that sets any
state on existing DateAndTime objects, not even their #offset.

Value objects are only ever created, and then their state never change
in 99% of cases. Magma treats DateAndTimes as immutable in the
database for performance -- it doesn't bother to check if they
changed.

Semantically, #utcOffset: doesn't mean anything to me. What is a "UTC
offset?" #nowWithOffset: sorts in the list next to #now, and makes
it abundantly clear to users what use-case it handles. I wish to keep
it.

Best,
Chris

Bert Freudenberg

Re: Status of date problem

On 19.03.2016, at 04:40, Chris Muller <[hidden email]> wrote:

>> 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.
>
> I wish to keep #nowWithOffset:. DateAndTime's are "value" objects --
> like Points and Fractions. I never want to write code that sets any
> state on existing DateAndTime objects, not even their #offset.

#offset: does return a new instance.

> Value objects are only ever created, and then their state never change
> in 99% of cases. Magma treats DateAndTimes as immutable in the
> database for performance -- it doesn't bother to check if they
> changed.

Yep. Same in general.

> Semantically, #utcOffset: doesn't mean anything to me. What is a "UTC
> offset?"

Agreed.

> #nowWithOffset: sorts in the list next to #now, and makes
> it abundantly clear to users what use-case it handles. I wish to keep
> it.

How about one character more? A space?

... now withOffset: ...

I think composability is preferable to an explosion of one-off specialized methods. I'd rather deprecate both #offset: and #utcOffset: and start doing the Right Thing.

- Bert -

smime.p7s (8K) Download Attachment

Max Leske

Re: Status of date problem

In reply to this post by Max Leske

On 19 Mar 2016, at 08:49, [hidden email] wrote:

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.

Yes, that fixes my problem. I still needed to make a small adaptation to reset the value of #automaticTimezone to the value used before the tests but that’s no issue.

Thanks for the fix. Great response time :)

Cheers,

Max

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 -

Bert Freudenberg

Re: Status of date problem

On 19.03.2016, at 11:40, Max Leske <[hidden email]> wrote:

On 19 Mar 2016, at 08:49, [hidden email] wrote:

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

Yes, that fixes my problem. I still needed to make a small adaptation to reset the value of #automaticTimezone to the value used before the tests but that’s no issue.

Well … if we could, I’d like to automate this, too.

Does the test save the previous time zone value, and restore it after?

If that’s the case we might re-enable the automatic time zone on the restore operation.

- Bert -

smime.p7s (5K) Download Attachment