The Trunk: Kernel-cmm.992.mcz

Chris Muller uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-cmm.992.mcz

==================== Summary ====================

Name: Kernel-cmm.992
Author: cmm
Time: 17 February 2016, 10:07:45.342973 pm
UUID: 06f233cb-83a0-466a-b96a-362a4d63864d
Ancestors: Kernel-bf.991

DateAndTime class>>#nowWithOffset: was part of the public API needed by applications.

=============== Diff against Kernel-bf.991 ===============

Item was added:
+ ----- Method: DateAndTime class>>nowWithOffset: (in category 'squeak protocol') -----
+ nowWithOffset: aDuration
+ ^ self
+ now: self clock localMicrosecondClockWithOffset first
+ offset: aDuration!

Item was changed:
  ----- Method: Timespan class>>current (in category 'squeak protocol') -----
  current
+ ^ self starting: (DateAndTime nowWithOffset: self defaultOffset)!
- ^ self starting: DateAndTime now!

Hi Chris,

there is no need that Timespan class>>current calls #nowWithOffset:. We should not suggest that we make actual use of aDuration if we do not. ;-) The API #nowWithOffset:, should stay in place for backwards compatibility.

Best,
Marcel

> On 17.02.2016, at 23:59, marcel.taeumel <[hidden email]> wrote:
>
> Hi Chris,
>
> there is no need that Timespan class>>current calls #nowWithOffset:.

It doesn’t. I changed that. Oh. Chris changed it back.

I had all the Chronology tests green, now TimespanTest>>testCurrent is failing again. I spent a couple hours yesterday making it all work.

Chris, please make the tests green again (without mucking around with the tests). Easiest would be to revert Timespan class>>current to my version.

> We
> should not suggest that we make actual use of aDuration if we do not. ;-)
> The API #nowWithOffset:, should stay in place for backwards compatibility.

If any we should deprecate it. It does not make sense. It’s as short to write “(… now offset: …)” with exactly the same (wrong) result. If it answered the same time (now) in a different timezone that would be okay, but that’s not what it does (that would be “… now utcOffset: …”. It does not give you “now” at all.

I did experiment with that, which is why the “now:offset:” method exists at all, but it would better be folded back into #now as the only entry point.

As I explained yesterday, Timespan uses its “defaultOffset” as a wildcard to mean “ignore the timezone” so any mucking around with the offset should be local to Timespan and not spill over into DateAndTime.

David is looking into rewriting Chronology to actually make sense, but this may take a while. For now we’ll have to live with this design.

- Bert -

Your guys' changes are moving a lot faster than I can keep up with.
I'm just trying to keep my apps alive.

To start:  I sometimes need to debug code for someone running in
another timezone.  Before, I could set or unset #useLocale as needed.
Now with this constant auto-update, it appears I no longer have any
control over that, so how can I simulate my image running in another
TimeZone?

In addition, the creation of Dates with Date today must not have a TZ
specified.  Your change broke that and I've added a test.

This may be a good time for all of us to go back to review those
discussions in early 2012..  Get ourselves refreshed on issues we
already typed about, and continue the discussion from there...

On 18.02.2016, at 13:29, Chris Muller <[hidden email]> wrote:
>
> Your guys' changes are moving a lot faster than I can keep up with.
> I'm just trying to keep my apps alive.
>
> To start:  I sometimes need to debug code for someone running in
> another timezone.  Before, I could set or unset #useLocale as needed.
> Now with this constant auto-update, it appears I no longer have any
> control over that, so how can I simulate my image running in another
> TimeZone?

Change your computer’s time.

> In addition, the creation of Dates with Date today must not have a TZ
> specified.  Your change broke that and I've added a test.

I’ll have a look.

- Bert -

On Thu, Feb 18, 2016 at 3:39 PM, Bert Freudenberg <[hidden email]> wrote:
You can't be serious.  Bert, I have 20 applications running on my
computer at once which depend on the clock.  I need to be able to
change it within each Squeak engine I have running.

useLocale has been working for a very long time.  It's very useful.  I
need it.  Can't we incorporate a check for it in your new code?

On 18.02.2016, at 13:29, Chris Muller <[hidden email]> wrote:
>
> In addition, the creation of Dates with Date today must not have a TZ
> specified.  Your change broke that and I've added a test.

This is a very arbitrary requirement you are imposing there. There is no DateAndTime without timezone. A zero offset does not mean “no timezone” but it means “UTC”.

It may very well be that we do want a Date without a Timezone. That’s why we need a rewrite of Chronology that allows that, and makes it explicit.

- Bert -

On 18.02.2016, at 13:45, Chris Muller <[hidden email]> wrote: How about a FakeTime object that you set as DateAndTime’s clock provider?

- Bert -

>> In addition, the creation of Dates with Date today must not have a TZ
>> specified.  Your change broke that and I've added a test.
>
> This is a very arbitrary requirement you are imposing there. There is no DateAndTime without timezone. A zero offset does not mean “no timezone” but it means “UTC”.

There is no DateAndTime without a TZ, but there are *Dates* without
TZ's.  There have been several discussions on the Squeak and Pharo
lists about this, it is not an arbitrary requirement in the least.
People want Dates without timezones more often than they want them
with.

Remember yesterday you mentioned how having another Date class to
support TZ's could be confusing?  I agree!  Well, with Chronology, we
don't need two, because it implements a Date as a Timespan with a
duration of 1-day.  So this brilliantly supports both families of
use-cases simultaneously; the ones that want to do *scheduling* (with
TZ's) and the ones that simply want Date positions (or Hour positions
or Minute positions), that compare quickly and successfully with other
Date/Hour/Minute positions (because Chronology implements those with
underlying offset of 0:00:00).

When I'm dealing with Dates as positions, I ignore the underlying
DateAndTime and its TimeZone.  It's just for Chronology's
implementation, which I don't need or want to concern myself with.

> It may very well be that we do want a Date without a Timezone. That’s why we need a rewrite of Chronology that allows that, and makes it explicit.

Timespan class>>#current explicitly specifies the #defaultOffset,
which has a detailed comment.

An offset of 0 in Chronology means that point in time is given in UTC. It does not mean there is no timezone.

> When I'm dealing with Dates as positions, I ignore the underlying
> DateAndTime and its TimeZone.  It's just for Chronology's
> implementation, which I don't need or want to concern myself with.
>
>> It may very well be that we do want a Date without a Timezone. That’s why we need a rewrite of Chronology that allows that, and makes it explicit.
>
> Timespan class>>#current explicitly specifies the #defaultOffset,
> which has a detailed comment.

Yes, that’s why I changed the equality check in Timespan to check for the defaultOffset and in that case ignore the time zone. I’ll do the same for magnitude comparison, which makes all tests green again. It’s the best we can do for now I think.

- Bert -

Okay, but according to your change of Timespan>>#=  yesterday:

         "defaultOffset means ignore time zone"

Bingo!

>> When I'm dealing with Dates as positions, I ignore the underlying
>> DateAndTime and its TimeZone.  It's just for Chronology's
>> implementation, which I don't need or want to concern myself with.

... and that is the point I tried to express, above (but was ignored).
For Dates, the underlying implementation can and should be
conveniently ignored just like encapsulation lets us do everywhere we
want to with OO.

>>> It may very well be that we do want a Date without a Timezone. That’s why we need a rewrite of Chronology that allows that, and makes it explicit.
>>
>> Timespan class>>#current explicitly specifies the #defaultOffset,
>> which has a detailed comment.
>
> Yes, that’s why I changed the equality check in Timespan to check for the defaultOffset and in that case ignore the time zone. I’ll do the same for magnitude comparison, which makes all tests green again. It’s the best we can do for now I think.

Not being able to run Squeak in the context of a remote timezone is a
huge downgrade.  I see no reason we should compromise, downgrade, or
break anything.   :(

Yes, but only in the context of Timespans.

> Not being able to run Squeak in the context of a remote timezone is a
> huge downgrade.  I see no reason we should compromise, downgrade, or
> break anything.   :(

I added a preference.

- Bert -