Is there a platform independent way to get UTC/GMT time?

[PhotonDemon]

Hi,

Is there a platform independent (Windows or UNIX) way to get UTC/GMT time? This:

Code: Select all

DateAndTime now asUTC

doesn't seem to work. It answers

2011-03-25T22:30:37.071+00:00

, which is an hour fast. I'm here in New Jersey (USA) and we are on Daylight Savings Time. Normally we are -5 hours from GMT but for the summer (on March 13th) we went to -4 hours.

"DateAndTime now" gets its values from Date and Time, which get there values from the VM via primitives. The primitives seem to answer the local machine time then "DateAndTime now asUTC" adjusts it to UTC but does it wrong because it doesn't take into account the summer time offset.

Is there a VM primitive that answers UTC time? If not, can we please have one? Maybe one that answers a DateAndTime or DateAndTime milliseconds or microseconds.

I know how to get UTC time from Windows but would like my code to work for both Windows and UNIX (and friends). This seems like a good candidate for the VM. Aren't there different VMs for different platforms? Couldn't each VM do what it needs to do to answer UTC time for the same primitive?

Is there a platform function that works for both Windows and UNIX (I know that doesn't make sense as a platform function but maybe it is wrapped well enough to hide the platform part). Or something like a DLL that works on both platforms.

Lou

[Thomas Holzer]

Hi Lou,

It seems, that this bug is still not fixed in VA 8.0.2. We run as well in this problem today after the summer time offset has changed yesterday.

This bug is from 2006 and has now a five years jubilee. Cheers!

Enclosed is a fix for Windows from Marten that works for me:

Regards Thomas

Code: Select all

primitiveSystemOffset
   "Answer an <Integer> representing the westward displacement of system local time
    from UTC in seconds.  The value can be between 0 and 86400 minutes."

   "http://groups.google.com/group/ibm.software.vasmalltalk/browse_thread/thread/6fa33d9022dc31df/d903c88e09e0dec6?lnk=gst&q=primitiveSystemOffset+#d903c88e09e0dec6"
   
   | daylightSavingInAction baseOffset dstOffset timezoneInformation |

   timezoneInformation := OSTimeZoneInformation calloc: 1.
   daylightSavingInAction := timezoneInformation getTimeZoneInformation.

   baseOffset := timezoneInformation Bias.
   dstOffset := timezoneInformation DaylightBias.

   timezoneInformation free.

   ^(baseOffset
     + (daylightSavingInAction= PlatformConstants::TimeZoneIdDaylight
         ifTrue: [ dstOffset]
         ifFalse: [ 0 ])) * 60




[tc]

Hello,

Is there a platform independent (Windows or UNIX) way to get UTC/GMT time?

There is but it is not straightforward. Java, for example distributes the Olsen Timezone Database (http://www.oracle.com/technetwork/java/javase/timezones-137583.html). Here are other articles:

http://www.chronos-st.org/Discovering%20the%20Local%20Time%20Zone--Why%20It%27s%20a%20Hard%20Problem.html
http://chronos-st.blogspot.com/2007/01/vw-2007-timezone-settings-for-north.html

--tc

[PhotonDemon]

Hi Thomas,

Thanks for the history and my buddy Marten's fix. I jumped from v5.5.2 to v8 and didn't know this was a problem back to v6.

As part of my upgrade to v8.0.3 I have been trying to clean up code and remove platform dependencies. I work in Windows but would like to be able to use many of my base classes in UNIX and Linux. I had two classes that had a Windows dependency that shouldn't have. They are in an app that shouldn't reference Windows platform classes.

I "fixed" my classes by changing them to using DateAndTime to get the UTC date and time in a platform independent way. I did this before DST rolled in and I didn't know of the bug. Now DST is here and it seems the only fix is to become Windows dependent again. That wouldn't be so bad but it means moving classes from one app to another or making the app they live in at least temporarily Windows dependent. This is a pain

Hi Instantiations guys, I don't like to tell others how easy it should be for them to fix or change something, so if I'm out of line please say so I don't see why it would be so hard to fix this in the VM. Marten has basically shown what would need to be done for the Windows VM. It might be harder under UNIX/Linux but I doubt it.

If it is too big a deal to fix #primitiveSystemOffset for both platforms, how about a new primitive that answers UTC time like I suggested in my first post? Pick a format for the answer like DateAndTime or whatever, I don't think the Windows code for this is too bad and UNIX should be even easier as I think it stores UTC time and not local time as I think Windows does.

Replacement Windows VMs would be good for me for now with UNIX to follow. This would allow me to have my now broken code fixed by just replacing the VM and not messing around with what class is in what app and the packaging problems that may follow

Lou

P.S. I see Taylor has pointed out that I could do something with the Olsen Timezone Database. One of my classes that needs UTC time is a timezone class that I use to answer times in different timezones but it starts with UTC.

[marten]

Last weekend I got my first Seaside project runnable under public condition (under Linux) and I ran into this error again - but now under Ubuntu 10.10. Here is code, which fixes this bug ... all system calls seem to be POSIX C calls. Please note the incorrect use of OSInt32 and pointer address access, but this code works and it should only show the the general principle:

Code: Select all

primitiveSystemOffset
   "Answer an <Integer> representing the westward displacement of system local time
    from UTC in seconds.  The value can be betwen 0 and 86400 minutes."

  | timeinfo localtimePF timePF timeT offset |

  "definition of platform functions under Ubuntu 10.10"
  timePF := PlatformFunction fromArray: #('c' 'time' nil 'libc.so.6' (pointer) void).
  localtimePF := PlatformFunction fromArray: #( 'c' 'localtime' nil 'libc.so.6' (pointer) pointer).

  "retrieve the local time"
  timeT := OSUInt64 new.
  timePF callWith: timeT.

  "convert local time to timeinfo ..."
  timeinfo := OSInt32 address: ( localtimePF callWith: timeT).

  "seconds east of UTC - it is defined as long int - but it seems to be int32 and not int64 !?

    timeinfo at: 8 returns information if DST is active or not
    (timeinfo at: 10) returns a pointer address to a a string containing timezone abbreviation
                               -> (OSStringZ address: (timeinfo at: 10) )asString

  "
  offset := timeinfo at: 9.
  "VA answers seconds west of UTC .. therefore change it ..."
  ^0-offset
   


To get the UTC time - well, get the local time, get the offset and then you can do it on your own ...

[PhotonDemon]

Hi Marten,

Thanks for the code. Where do you keep the two copies (Windows & UNIX) of #primitiveSystemOffset?

I used your Windows code but moved it to my own Windows platform app. Do you have a Windows platform app and a UNIX platform app where you keep the two different methods?

Lou

[marten]

Though I would always resist to change the delivered application I simply do this ... change the delivered applications of Instantiations. Because I want that also the system code works correctly. I only deliver code for Windows and Linux - therefore I have no need to check this code against AIX or Solaris and I think, that my code will break the Solaris and AIX code ... but I do not care about this right now ... that's the work for Instantiations

Hi Marten,

Thanks for the code. Where do you keep the two copies (Windows & UNIX) of #primitiveSystemOffset?

[PhotonDemon]

Hi Marten,

Snip... I only deliver code for Windows and Linux - therefore I have no need to check this code against AIX or Solaris and I think, that my code will break the Solaris and AIX code ... but I do not care about this right now ... that's the work for Instantiations

Agreed. When I mentioned UNIX I was being generic and actually meant Linux. The code you show above looks like it only works for Linux and not Windows (which you have previously posted). So, do you save the two versions in two different platform apps and load them with different config maps?

Thanks, Lou

P.S. Could Instantiations chime in here with an estimate for when the problem will be fixed. And maybe a best practices way of using Martens code

[marten]

That would be the better (in terms of structuring and speed) way, but actually I keep it simply right now and check for the platform (Unix or Windows) in Smalltalk and call different methods.

So, do you save the two versions in two different platform apps and load them with different config maps?

[koschate]

That would be the better (in terms of structuring and speed) way, but actually I keep it simply right now and check for the platform (Unix or Windows) in Smalltalk and call different methods.

Personally, I'd be inclined to move the method to conditionally loaded subapplications. That way it could have the same name on any platform, and you're not doing platform determination at runtime.

[marten]

Totally correct !

Personally, I'd be inclined to move the method to conditionally loaded subapplications. That way it could have the same name on any platform, and you're not doing platform determination at runtime.

[PhotonDemon]

Hi koschate,

Personally, I'd be inclined to move the method to conditionally loaded subapplications. That way it could have the same name on any platform, and you're not doing platform determination at runtime.

I'm interested in settings things up this way but lack the experience with config maps to know just how to proceed. I have an app with some Windows platform objects in which I put Marten's Windows version of #primitiveSystemOffset. Should I make an new app for Marten's Linux version?

Or, should I make two sub-applications (one for Windows and one for Linux) of my current platform app and move the Windows stuff to the Windows sup-app and Marten's Linux version to the Linux sup-app?

Thanks for any help you can give, Lou

[marten]

a) "I'm interested in settings things up this way but lack the experience with config maps to know just how to proceed. I have an app with some Windows platform objects in which I put Marten's Windows version of #primitiveSystemOffset. Should I make an new app for Marten's Linux version?"

b) "Or, should I make two sub-applications (one for Windows and one for Linux) of my current platform app and move the Windows stuff to the Windows sup-app and Marten's Linux version to the Linux sup-app?"

Only the later approach is working correctly. The main reasons for this are "prerequisites" of your application. In the first approach you have different applications, where the code is located in. Now consider: how can you define the prerequisites of an platform independent applications using your platform dependent code ? The prerequisites will be either right for Windows or for Linux - but not for both.

In the later approach you have the same application (therefore the prerequisites are the same), but when loading the system loads different platform dependent code.

[koschate]

Or, should I make two sub-applications (one for Windows and one for Linux) of my current platform app and move the Windows stuff to the Windows sup-app and Marten's Linux version to the Linux sup-app?

As Marten said, the correct way to approach this would be have two sub apps. The CommonGraphics application is an interesting place to start looking at approaches.

It can be little tricky to get things set up since you'll have to have the subapp versioned and released into their respective configs before you can version the application itself. I normally end up creating a subapp in the target environment with an unconditional config expression of 'true', testing, versioning, and then deleting the subapp. Then I switch to the other environment and do the same thing, creating a new subapp. Finally, I delete the unconditional expression, add the first conditional expression, release the appropriate subapp into it, add the next config expression, and release the appropriate subapp into that. Then I can version the application.

Note that the application prereqs are actually defined on the subapp, since different subapps may have different prereqs.