Date tomorrow - Date today "0:19:00:00"

I expected to get 1 day.  19 hours is clearly wrong isn't it?

Check out DateAndTime>>#-.  When I remove those #asLocal calls, I get
the expected result (1 day).  But it seems like it should work even
with them -- because it subtracts a DateAndTime exactly 24 hours away
(each in local time) but constructs a Duration of 19 hours...??

On 28.06.2012, at 02:58, Chris Muller wrote:

> I expected to get 1 day.  19 hours is clearly wrong isn't it?
>
> Check out DateAndTime>>#-.  When I remove those #asLocal calls, I get
> the expected result (1 day).  But it seems like it should work even
> with them -- because it subtracts a DateAndTime exactly 24 hours away
> (each in local time) but constructs a Duration of 19 hours...??


Yep, something's broken. The tests in Kernel-Chronology report 11 failures.

- Bert -

It's just a bad reference to self localOffset rather than the specified offset in todayAtNanoSeconds:offset: (see below). Changing the reference to aDuration fixes the problem. Usually todayAtMilliseconds:offset: is used. todayAtNanoSeconds:offset is only used when a call to nowWithOffset: results in the same tick value as the previous call.

        todayAtNanoSeconds: nanoSecondsSinceMidnight offset: aDuration

                "This is usually only during system startup..."
                self waitForOffsets.

                ^ self basicNew
                        setJdn: DaysSinceEpoch
                        seconds: (nanoSecondsSinceMidnight // 1000000000)
                        nano: (nanoSecondsSinceMidnight  \\ 1000000000  )
                        offset: self localOffset       

This doesn't help with the Chronology test failures. I'll have a look at them.

Glen Paling

On 03.07.2012, at 18:16, glenpaling wrote:

Great! Committed to trunk.

> This doesn't help with the Chronology test failures. I'll have a look at
> them.
>
> Glen Paling


Thanks!

- Bert -

Chris M in particular,

On 03.07.2012, at 18:33, Bert Freudenberg wrote:


Shouldn't this be a private method?

This method relies on DaysSinceEpoch being set to the right day. That means it's only safe to use from #nowWithOffset: which precedes it with a call to #milliSecondsSinceMidnight which is the only method that adjusts DaysSinceEpoch.

Who is using the #todayAt... methods anyway? No other sender in the image.

How about inlining these into #nowWithOffset: and removing them altogether?

- Bert -