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 - |
In reply to this post by Chris Muller-3
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:
> 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* 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: > On 03.07.2012, at 18:16, glenpaling wrote: > >> 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* > > Great! Committed to trunk. 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 - |
Free forum by Nabble | Edit this page |