For OLPC I need a UTC time stamp, and found VM's behaviors to differ widely.
All VMs currently report time as local time. To identify those VMs we need a primitive that answers the offset of the VM time from local time. This could nicely fallback to 0 if no LocalePlugin is available. Then we also need a primitive to determine the offset of local time from UTC.
The locale plugin currently has three related primitives:
==================================== http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins/LocalePlugin/Lo...
/* return in minutes the offset between thisVM and UTC. */ sqInt sqLocGetVMOffsetToUTC(void);
/* return in minutes the offset between the currenct timezone and UTC */ sqInt sqLocGetTimezoneOffset(void);
/* return true if DST is in use, false otherwise */ sqInt sqLocDaylightSavings(void); ====================================
IMHO these are insufficient, besides they do not work the same on all platforms. Here's what I get in Germany with DST in effect:
platform Win Mac Linux vm offset 0 0 -120 timezone 60 120 -120 daylight true true true
So VMOffsetToUTC is reported as 0 by Mac and Win - I think that primitive is simply misnamed, which led to the wrong implementation in Linux. If the VM answers local time this should be 0. (we might simply declare the VM is always in local time and get rid of this prim entirely)
The TimezoneOffset should be counted EAST of Greenwich, this wasn't really specified in the header so that's why Linux got it wrong (Unix timezones are typically counted West). This *should* include DST adjustment IMHO as Mac and Win do. It really is the offset between local time and UTC.
So I propose to redefine the primitives as follows:
====================================
/* return in minutes the offset between local time and this VM. this value plus the time reported by the VM gives local time. 0 indicates VM answers local time. If VM answers UTC, in Berlin in Summer this would be +120 */ sqInt sqLocGetVMOffset(void);
/* return in minutes the offset between local time and UTC where positive values are East of Greenwich. e.g., Berlin in Summer is +120 in Winter +60 */ sqInt sqLocGetUTCOffset(void);
/* return true if DST is in use, false otherwise */ sqInt sqLocDaylightSavings(void); ====================================
As far as I am aware, nobody used these primitives yet. If renaming is too much hassle we could leave the old wrong names but add the comments as I proposed above, and adjust the behavior. Mac then would already be compliant, Windows is only off by an hour (in Summer?), and I'll fix Linux in the OLPC branch.
Comments?
- Bert -
On Thu, Aug 28, 2008 at 01:22:32PM +0200, Bert Freudenberg wrote:
For OLPC I need a UTC time stamp, and found VM's behaviors to differ widely.
All VMs currently report time as local time. To identify those VMs we need a primitive that answers the offset of the VM time from local time. This could nicely fallback to 0 if no LocalePlugin is available. Then we also need a primitive to determine the offset of local time from UTC.
The locale plugin currently has three related primitives:
<snip>
As far as I am aware, nobody used these primitives yet. If renaming is too much hassle we could leave the old wrong names but add the comments as I proposed above, and adjust the behavior. Mac then would already be compliant, Windows is only off by an hour (in Summer?), and I'll fix Linux in the OLPC branch.
Comments?
Hi Bert,
The approach that I prefer, proposed by Lex Spoon some time ago, is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-February/020250....
See the plugin attached to that email. It's a simple primitive that nowadays you could just incorporate into the LocalePlugin.
FYI, Squeak can fully handle local time zones without any plugin support at all:
http://www.squeaksource.com/TimeZoneDatabase/ http://wiki.squeak.org/squeak/1076
But this may be too heavyweight for OLPC use.
Dave
Am 28.08.2008 um 13:58 schrieb David T. Lewis:
On Thu, Aug 28, 2008 at 01:22:32PM +0200, Bert Freudenberg wrote:
For OLPC I need a UTC time stamp, and found VM's behaviors to differ widely.
All VMs currently report time as local time. To identify those VMs we need a primitive that answers the offset of the VM time from local time. This could nicely fallback to 0 if no LocalePlugin is available. Then we also need a primitive to determine the offset of local time from UTC.
The locale plugin currently has three related primitives:
<snip>
As far as I am aware, nobody used these primitives yet. If renaming is too much hassle we could leave the old wrong names but add the comments as I proposed above, and adjust the behavior. Mac then would already be compliant, Windows is only off by an hour (in Summer?), and I'll fix Linux in the OLPC branch.
Comments?
Hi Bert,
The approach that I prefer, proposed by Lex Spoon some time ago, is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-February/020250....
See the plugin attached to that email. It's a simple primitive that nowadays you could just incorporate into the LocalePlugin.
Why would you prefer that approach? The LocalePlugin pretty much works, it just as to be made work consistently.
FYI, Squeak can fully handle local time zones without any plugin support at all:
How would it find out the current time zone then?
- Bert -
On Thu, Aug 28, 2008 at 02:07:48PM +0200, Bert Freudenberg wrote:
Am 28.08.2008 um 13:58 schrieb David T. Lewis:
The approach that I prefer, proposed by Lex Spoon some time ago, is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-February/020250....
See the plugin attached to that email. It's a simple primitive that nowadays you could just incorporate into the LocalePlugin.
Why would you prefer that approach? The LocalePlugin pretty much works, it just as to be made work consistently.
Lex's idea was to have one primitive that reported both UTC and offset as a single primitive operation. That is simple and still makes sense to me, so if you were to implement a new primitive to replace the current inconsistent one, this would still be my suggestion. To be honest I did not look at the LocalePlugin implementations at all. Your question just reminded me that the problem was "solved" long ago but never implemented.
FYI, Squeak can fully handle local time zones without any plugin support at all:
How would it find out the current time zone then?
You have to specify your local time zone in the image to select the correct time zone table, the same as is done for an operating system. This is not what you would want for OLPC, it's more appropriate for e.g. a Squeak web server application.
Dave
Comments?
We are using these primitives. Let me check with Brad if your observations ring a bell (he did most of that work).
Cheers, - Andreas
Bert Freudenberg wrote:
For OLPC I need a UTC time stamp, and found VM's behaviors to differ widely.
All VMs currently report time as local time. To identify those VMs we need a primitive that answers the offset of the VM time from local time. This could nicely fallback to 0 if no LocalePlugin is available. Then we also need a primitive to determine the offset of local time from UTC.
The locale plugin currently has three related primitives:
==================================== http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins/LocalePlugin/Lo...
/* return in minutes the offset between thisVM and UTC. */ sqInt sqLocGetVMOffsetToUTC(void);
/* return in minutes the offset between the currenct timezone and UTC */ sqInt sqLocGetTimezoneOffset(void);
/* return true if DST is in use, false otherwise */ sqInt sqLocDaylightSavings(void); ====================================
IMHO these are insufficient, besides they do not work the same on all platforms. Here's what I get in Germany with DST in effect:
platform Win Mac Linux vm offset 0 0 -120 timezone 60 120 -120 daylight true true true
So VMOffsetToUTC is reported as 0 by Mac and Win - I think that primitive is simply misnamed, which led to the wrong implementation in Linux. If the VM answers local time this should be 0. (we might simply declare the VM is always in local time and get rid of this prim entirely)
The TimezoneOffset should be counted EAST of Greenwich, this wasn't really specified in the header so that's why Linux got it wrong (Unix timezones are typically counted West). This *should* include DST adjustment IMHO as Mac and Win do. It really is the offset between local time and UTC.
So I propose to redefine the primitives as follows:
====================================
/* return in minutes the offset between local time and this VM. this value plus the time reported by the VM gives local time. 0 indicates VM answers local time. If VM answers UTC, in Berlin in Summer this would be +120 */ sqInt sqLocGetVMOffset(void);
/* return in minutes the offset between local time and UTC where positive values are East of Greenwich. e.g., Berlin in Summer is +120 in Winter +60 */ sqInt sqLocGetUTCOffset(void);
/* return true if DST is in use, false otherwise */ sqInt sqLocDaylightSavings(void); ====================================
As far as I am aware, nobody used these primitives yet. If renaming is too much hassle we could leave the old wrong names but add the comments as I proposed above, and adjust the behavior. Mac then would already be compliant, Windows is only off by an hour (in Summer?), and I'll fix Linux in the OLPC branch.
Comments?
- Bert -
Hi Bert -
Looks like we're in violent agreement (Brad's note attached). I checked in the fix for the Windows VM and here is the code that we use in the Unix locale plugin:
sqInt sqLocGetVMOffsetToUTC(void) { return 0; }
sqInt sqLocGetTimezoneOffset(void) { struct tm * timeBlock; time_t theTime; theTime = time((time_t)NULL); timeBlock = localtime(&theTime); return timeBlock->tm_gmtoff / 60; }
sqInt sqLocDaylightSavings(void) { struct tm * timeBlock; time_t theTime; theTime = time((time_t)NULL); timeBlock = localtime(&theTime); return timeBlock->tm_isdst; }
Cheers, - Andreas
Am 28.08.2008 um 18:58 schrieb Andreas Raab:
Hi Bert -
Looks like we're in violent agreement (Brad's note attached).
Great!
I checked in the fix for the Windows VM and here is the code that we use in the Unix locale plugin:
sqInt sqLocGetVMOffsetToUTC(void) { return 0; }
sqInt sqLocGetTimezoneOffset(void) { struct tm * timeBlock; time_t theTime; theTime = time((time_t)NULL); timeBlock = localtime(&theTime); return timeBlock->tm_gmtoff / 60; }
sqInt sqLocDaylightSavings(void) { struct tm * timeBlock; time_t theTime; theTime = time((time_t)NULL); timeBlock = localtime(&theTime); return timeBlock->tm_isdst; }
Mine looks pretty similar. It's written to be the reverse of convertToSqueakTime() which is special-cased to work across a variety of Unices (tm_gmtoff is a BSDism, also in glibc, but not strict ISO C).
I'll fix the DST function too, didn't need it for now.
Btw, in the OLPC image we use it like this:
http://tinlizzie.org/updates/etoys/updates/2092LocalePluginAddins-tpr.cs http://tinlizzie.org/updates/etoys/updates/2106chronologyUnix-bf.cs
Do you use other functions from the locale plugin? I noticed at least the format methods are not correct under Linux, too ...
- Bert -
Do you use other functions from the locale plugin? I noticed at least the format methods are not correct under Linux, too ...
Currently we only use the time zone functions.
Cheers, - Andreas
Bert Freudenberg wrote:
Am 28.08.2008 um 18:58 schrieb Andreas Raab:
Hi Bert -
Looks like we're in violent agreement (Brad's note attached).
Great!
I checked in the fix for the Windows VM and here is the code that we use in the Unix locale plugin:
sqInt sqLocGetVMOffsetToUTC(void) { return 0; }
sqInt sqLocGetTimezoneOffset(void) { struct tm * timeBlock; time_t theTime; theTime = time((time_t)NULL); timeBlock = localtime(&theTime); return timeBlock->tm_gmtoff / 60; }
sqInt sqLocDaylightSavings(void) { struct tm * timeBlock; time_t theTime; theTime = time((time_t)NULL); timeBlock = localtime(&theTime); return timeBlock->tm_isdst; }
Mine looks pretty similar. It's written to be the reverse of convertToSqueakTime() which is special-cased to work across a variety of Unices (tm_gmtoff is a BSDism, also in glibc, but not strict ISO C).
I'll fix the DST function too, didn't need it for now.
Btw, in the OLPC image we use it like this:
http://tinlizzie.org/updates/etoys/updates/2092LocalePluginAddins-tpr.cs http://tinlizzie.org/updates/etoys/updates/2106chronologyUnix-bf.cs
Do you use other functions from the locale plugin? I noticed at least the format methods are not correct under Linux, too ...
- Bert -
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
David T. Lewis