Timezones in LocalePlugin
Locked
 
|
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/LocalePlugin.h /* 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.html 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 |
Re: Timezones in LocalePlugin
|
|
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.html > > 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.html > > > >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 |
|
|
In reply to this post by Bert Freudenberg
> 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/LocalePlugin.h > > > /* 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 - > > |
|
|
In reply to this post by Bert Freudenberg
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 Then we're ahead of the curve... the changes I made to windows and unix were to have them do that - return dst-adjusted from getTimezoneOffset, and correct indicator from sqLocDaylightSavings The win primitive wasn't dst-adjusted before my change, and the Unix one was just out of whack, relying on a weird older glibc trick IIRC. -b > > > Brad Fowlow wrote: >> I'm not quite sure I understand what difference he's proposing >> between these two... >>>>> /* return in minutes the offset between thisVM and UTC. */ >>>>> sqInt sqLocGetVMOffsetToUTC(void); > > This is only meant to indicate whether the VM uses UTC or local > internally - answering 0 is always okay for a VM with local time. > >>>>> /* return in minutes the offset between the currenct timezone >>>>> and UTC */ >>>>> sqInt sqLocGetTimezoneOffset(void); > > This one should return the offset between local time and UTC > counting east and including DST adjustments (when in effect). > >> Our VM's report local time in raw local times always, >> and so the second primitive above is always used to create a >> utcSeconds time. > > That sounds identical - I wasn't quite sure if the prims we use > include DST adjustments or not. > >> If he's proposing to have the VM's themselves do that differently >> and use that first primitive to adjust, then no we're probably not. > > No, not really. What Bert actually proposed is to drop the first > prim and assume that the VMs are always in local time ;-) > > Cheers, > - Andreas > >> -b >>> And are our VMs in line with Bert's proposal? >>> >>> - A. >>> >>> Brad Fowlow wrote: >>>> sqLocGetVMOffset we don't rely on, and is unchanged. >>>> Our VM's for Mac, Windows (since Nov 2007), and (recently) unix >>>> have correct >>>> sqLocGetTimezoneOffset(void) >>>> sqLocDaylightSavings(void) >>>> so in our VM's, these 2 primitives are correct on the platforms, >>>> and suffice to construct utc-times. >>>> - b >>>>> The locale plugin currently has three related primitives: >>>>> >>>>> ==================================== >>>>> http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins/LocalePlugin/LocalePlugin.h >>>>> >>>>> /* 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 |
Re: Timezones in LocalePlugin
|
|
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 - > > |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |