Issue 228 in glassdb: Time now asDateAndTime "not always" <= DateAndTime now

Status: Accepted
Owner: [hidden email]
Labels: Type-Defect Priority-Medium GLASS-Server Version-1.0-beta.8  
Milestone-1.0-beta.8.6

New issue 228 by [hidden email]: Time now asDateAndTime  "not always"  
<= DateAndTime now
http://code.google.com/p/glassdb/issues/detail?id=228

I haven't put all of the pieces together yet. The first hint came from Max  
Leske when he reported that SqueakTests>>#testDateArithmetic  was failing  
on his Mac:

   http://forum.world.st/failing-tests-td3244020.html

The odd thing is that I couldn't reproduce the test failure until today  
when I ran the tests in a fresh ubunutu10.10 vmware appliance...

In separate email Max has noted the following:

"#testDateArithmetic
The failing line is: "self assert: Time now asDateAndTime  <= DateAndTime  
now".

"Time now asDateAndTime" evaluates to: 2011-02-01T21:01:51-08:00.
The number of seconds of this object are: 318315819.

"DateAndTime now" evaluates to: 2011-02-01T12:02:48.1668438911438-08:00
The number of seconds of this object are: 3,1828354650827408E+08.
The offset is the same for both objects.
The difference is a Duration of 0:08:59:59.2.

So why the crazy seconds?
The reason lies in DateAndTime>>secondsSince2001. The statement: "System  
_timeGmtFloat - 978307200" evaluates to: 3,1828371659105110E+08.
Even when truncated the SmallDouble value is much smaller than the SmallInt  
one.
My guess is again that there's a problem with the primitive for  
#_timeTmtFloat because the primitive used by Time class>>now seems to  
answer the correct value."

The above information while valid doesn't explain why the tests don't fail  
in my test environment ... the additional piece of information that  
probably makes a difference is that the new appliance is set to EST and my  
test environment is set to PST ... so at least I have a test environment  
where I can finally characterize the problem..

Comment #1 on issue 228 by [hidden email]: Time now asDateAndTime  "not  
always" <= DateAndTime now
http://code.google.com/p/glassdb/issues/detail?id=228

It looks like the following implementation of Time>>asDateAndTime fixes the  
problem:

   asDateAndTime

        ^ DateAndTime today + (Duration seconds: self asSecondsGmt)

DateAndTime tracks the timezone offset separately, while the offset is  
embedded in the seconds of the Time instance so to do proper arithmetic  
between the two, the timezone offset must be removed from the Time as the  
offset is added back in by the DateAndTime instance...

I need to do more testing and investigation and find more tests that do  
mixed type arithmetic...Time>>asDuration is suspect without knowing whether  
the timezone offset is to be included or not...

Comment #2 on issue 228 by [hidden email]: Time now asDateAndTime  "not  
always" <= DateAndTime now
http://code.google.com/p/glassdb/issues/detail?id=228

By default GemStone ships with the timezone set to PST and 'Time now' uses  
the timezone of the host which is where the difference is actually coming  
from...a discrepancy between the repository-based timezone and the timezone  
used by the host os ...

Nick Ager provides information about synchronizing the repository-based  
info to the host-based info in this thread:

   http://forum.world.st/TimeZone-td3001035.html

but I notice that Juan still had a problem with TimeStamp synchronizing  
correctly (sorry about that Juan) ... so I will look at the TimeStamp  
implementation to ensure that it matches Time and DateAndTime ...

I am going to consider adding timezone synchronization to the GLASS update  
script so that the timezones don't have to be manually synchronized ...

Comment #3 on issue 228 by [hidden email]: Time now asDateAndTime  "not  
always" <= DateAndTime now
http://code.google.com/p/glassdb/issues/detail?id=228

if it wasn't clear from my previous comment ... the implementation of  
Time>>asDateAndTime isn't the issue ... the issue is that Time and  
DateAndTime derive their times from different os calls and are noticeable  
affected if the os timezone and repository timezone are not in sync

Updates:
        Labels: bugid-41281

Comment #4 on issue 228 by [hidden email]: Time now asDateAndTime  "not  
always" <= DateAndTime now
http://code.google.com/p/glassdb/issues/detail?id=228

....finally the root cause.

In GemStone, `Time now` uses a primitive call to get the time since  
midnight including the `TimeZone fromOS` offset. `DateAndTime now` uses a  
primitive call to get the gmt seconds since an epoc and calculates an  
offset based upon `TimeZone current`.

If `TimeZone current` and `TimeZone fromOS` are not the same then  
inconsistencies will occur.

Since you are supposed to be able to set `TimeZone current` to something  
other than `TimeZone fromOS` the bug is actually in Time now.

 From the GemStone bugreport for bug41281:

   One option is to rename the existing #'now' method to #'_now' and  
replacing the existing
   one with something like the following:

   now
        "See _now for a shortcut that gets the time from the OS"

        | parts secondsSinceMidnight |
        parts := DateAndTime now asFloatParts. "#(year dayOfYear monthIndex  
dayOfMonth
                                                    hour minute second)"
        secondsSinceMidnight := (parts at: 5) * 60 + (parts at: 6) * 60 + (parts  
at: 7).
        ^self fromMilliseconds: (secondsSinceMidnight * 1000) rounded.


Another option is to make sure that the OS and GemStone are set to the same  
TimeZone, Using the technique described by Nick Ager:

   http://forum.world.st/TimeZone-tp3001035p3001106.html

Updates:
        Labels: -Milestone-1.0-beta.8.6 Milestone-1.0-beta.8.7

Comment #5 on issue 228 by [hidden email]: Time now asDateAndTime  "not  
always" <= DateAndTime now
http://code.google.com/p/glassdb/issues/detail?id=228

(No comment was entered for this change.)

Updates:
        Status: Started

Comment #6 on issue 228 by [hidden email]: Time now  
asDateAndTime  "not always" <= DateAndTime now
http://code.google.com/p/glassdb/issues/detail?id=228

bug 41281 is fixed in GemStone 3.0 ... need to integrate the fix ...

Updates:
        Labels: -Version-1.0-beta.8 Version-3.0.x

Comment #7 on issue 228 by [hidden email]: Time now  
asDateAndTime  "not always" <= DateAndTime now
http://code.google.com/p/glassdb/issues/detail?id=228

(No comment was entered for this change.)

Updates:
        Status: Fixed

Comment #8 on issue 228 by [hidden email]: Time now  
asDateAndTime  "not always" <= DateAndTime now
http://code.google.com/p/glassdb/issues/detail?id=228

This bug is fixed in GemStone 3.0  (Build 25262).

Here's the 3.0 method:

now
   "Beginning with Gs64 v3.0, returns an instance of the receiver  
representing
    the current time, taking into consideration the current smalltalk  
TimeZone ,
    per class DateAndTime .

    See Time(C)>>_now for previous implementation that gets time directly  
from the OS."

    | parts secondsSinceMidnight |
    parts := DateAndTime now asFloatParts.
      "parts is { year. dayOfYear. monthIndex. dayOfMonth. hour. minute.  
second } "
    secondsSinceMidnight := (parts at: 5) * 60 + (parts at: 6) * 60 + (parts  
at: 7).
    ^self fromMilliseconds: (secondsSinceMidnight * 1000) rounded.

This method should work in 2.4 and I'd include the fix in an mcz file, but  
you have to be SystemUser to compile a primitive...which is required to  
move the existing Time class>>now method to Time class>>_now