Should a long running image notice daylight saving?
Locked
Should a long running image notice daylight saving?
 
|
Hi all,
I have a long running 5.1 image on a Raspi A+ which regularly waits on a Delay. Raspbian has noticed daylight saving, Squeak not. Is this expected and what can I do with the running image to make it notice? Except waiting for the monthly crash and restart :-) Cheers, Herbert |
Re: Should a long running image notice daylight saving?
|
|
Hi Herbert,
This issue was discussed[1] here recently. I suggested[2] a VM change to solve this problem, but the same thing can be done on the image side too. Just change Time class >> #utcMicrosecondClockWithOffset to be: utcMicrosecondClockWithOffset "Answer an array with UTC microseconds since the Smalltalk epoch and the current seconds offset from UTC in the local time zone." | utc currentMinute | utc := self utcMicrosecondClock. currentMinute := utc // 60000000. LastTimeTimeZoneWasUpdated = currentMinute ifFalse: [ LastTimeTimeZoneWasUpdated := currentMinute. TimeZoneOffset := Locale current primTimezone * 60 ]. ^{ utc. TimeZoneOffset } and Time class >> #localMicrosecondClock to be: localMicrosecondClock "Answer the local microseconds since the Smalltalk epoch (January 1st 1901, the start of the 20th century). The value is derived from the current UTC wallclock time and the image's current notion of time zone." | utcMicrosecondClockWithOffset | utcMicrosecondClockWithOffset := self utcMicrosecondClockWithOffset. ^(utcMicrosecondClockWithOffset at: 2) * 1000000 + (utcMicrosecondClockWithOffset at: 1) LastTimeTimeZoneWasUpdated and TimeZoneOffset should be class variables. They don't have to be initialized. Levente [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193594.html [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193638.html On Sun, 2 Apr 2017, Herbert König wrote: > Hi all, > > I have a long running 5.1 image on a Raspi A+ which regularly waits on a > Delay. > > Raspbian has noticed daylight saving, Squeak not. > > Is this expected and what can I do with the running image to make it > notice? Except waiting for the monthly crash and restart :-) > > > Cheers, > > Herbert > > > |
Re: Should a long running image notice daylight saving?
|
|
Hi Levente, thanks, it works. I even had read the discussion and somehow
misread that it was about moving from one timezone to another. :-( Cheers,
Herbert Am 02.04.2017 um 14:08 schrieb Levente
Uzonyi:
Hi Herbert, |
Re: Should a long running image notice daylight saving?
|
|
In reply to this post by Levente Uzonyi
Or do it like this, which does not require LocalePlugin:
localMicrosecondClockDave | timeArray | timeArray := self primPosixMicrosecondClockWithOffset. ^timeArray first + ((2177452800 + timeArray second) * 1000000). Dave On Sun, Apr 02, 2017 at 02:08:07PM +0200, Levente Uzonyi wrote: > Hi Herbert, > > This issue was discussed[1] here recently. I suggested[2] a VM change to > solve this problem, but the same thing can be done on the image side too. > Just change Time class >> #utcMicrosecondClockWithOffset to be: > > utcMicrosecondClockWithOffset > "Answer an array with UTC microseconds since the Smalltalk epoch and > the > current seconds offset from UTC in the local time zone." > > | utc currentMinute | > utc := self utcMicrosecondClock. > currentMinute := utc // 60000000. > LastTimeTimeZoneWasUpdated = currentMinute ifFalse: [ > LastTimeTimeZoneWasUpdated := currentMinute. > TimeZoneOffset := Locale current primTimezone * 60 ]. > ^{ utc. TimeZoneOffset } > > and Time class >> #localMicrosecondClock to be: > > localMicrosecondClock > "Answer the local microseconds since the Smalltalk epoch (January > 1st 1901, the start of the 20th century). > The value is derived from the current UTC wallclock time and the > image's current notion of time zone." > > | utcMicrosecondClockWithOffset | > utcMicrosecondClockWithOffset := self utcMicrosecondClockWithOffset. > ^(utcMicrosecondClockWithOffset at: 2) * 1000000 + > (utcMicrosecondClockWithOffset at: 1) > > > LastTimeTimeZoneWasUpdated and TimeZoneOffset should be class variables. > They don't have to be initialized. > > Levente > > [1] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193594.html > [2] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193638.html > > On Sun, 2 Apr 2017, Herbert K?nig wrote: > > >Hi all, > > > >I have a long running 5.1 image on a Raspi A+ which regularly waits on a > >Delay. > > > >Raspbian has noticed daylight saving, Squeak not. > > > >Is this expected and what can I do with the running image to make it > >notice? Except waiting for the monthly crash and restart :-) > > > > > >Cheers, > > > >Herbert > > > > > > > |
Re: Should a long running image notice daylight saving?
|
|
I think I'm getting myself confused with too many images with different
DateAndTime flavors. We already have primitiveLocalMicrosecondClock that can be called with primLocalMicrosecondClock, which hopefully does the same thing as my snippet below. Dave On Sun, Apr 02, 2017 at 10:48:00AM -0400, David T. Lewis wrote: > Or do it like this, which does not require LocalePlugin: > > localMicrosecondClockDave > | timeArray | > timeArray := self primPosixMicrosecondClockWithOffset. > ^timeArray first + ((2177452800 + timeArray second) * 1000000). > > Dave > > > On Sun, Apr 02, 2017 at 02:08:07PM +0200, Levente Uzonyi wrote: > > Hi Herbert, > > > > This issue was discussed[1] here recently. I suggested[2] a VM change to > > solve this problem, but the same thing can be done on the image side too. > > Just change Time class >> #utcMicrosecondClockWithOffset to be: > > > > utcMicrosecondClockWithOffset > > "Answer an array with UTC microseconds since the Smalltalk epoch and > > the > > current seconds offset from UTC in the local time zone." > > > > | utc currentMinute | > > utc := self utcMicrosecondClock. > > currentMinute := utc // 60000000. > > LastTimeTimeZoneWasUpdated = currentMinute ifFalse: [ > > LastTimeTimeZoneWasUpdated := currentMinute. > > TimeZoneOffset := Locale current primTimezone * 60 ]. > > ^{ utc. TimeZoneOffset } > > > > and Time class >> #localMicrosecondClock to be: > > > > localMicrosecondClock > > "Answer the local microseconds since the Smalltalk epoch (January > > 1st 1901, the start of the 20th century). > > The value is derived from the current UTC wallclock time and the > > image's current notion of time zone." > > > > | utcMicrosecondClockWithOffset | > > utcMicrosecondClockWithOffset := self utcMicrosecondClockWithOffset. > > ^(utcMicrosecondClockWithOffset at: 2) * 1000000 + > > (utcMicrosecondClockWithOffset at: 1) > > > > > > LastTimeTimeZoneWasUpdated and TimeZoneOffset should be class variables. > > They don't have to be initialized. > > > > Levente > > > > [1] > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193594.html > > [2] > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193638.html > > > > On Sun, 2 Apr 2017, Herbert K?nig wrote: > > > > >Hi all, > > > > > >I have a long running 5.1 image on a Raspi A+ which regularly waits on a > > >Delay. > > > > > >Raspbian has noticed daylight saving, Squeak not. > > > > > >Is this expected and what can I do with the running image to make it > > >notice? Except waiting for the monthly crash and restart :-) > > > > > > > > >Cheers, > > > > > >Herbert > > > > > > > > > > > > > > |
Re: Should a long running image notice daylight saving?
|
|
Hi Dave,
As I mentioned before, the problem with that primitive is that it doesn't update the offset when the time zone changes. Here's an example from an image which was started in UTC+1, but is in UTC+2 right now: { Time primPosixMicrosecondClockWithOffset. Locale current primTimezone } "#(#(1491158588541139 3600) 120)" VM info: /squeak/products/cogspur64linuxht/lib/squeak/5.0-201609151123/squeak Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.1950] Unix built on Sep 15 2016 11:24:50 Compiler: 4.6.3 platform sources revision VM: 201609151123 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Sep 15 13:23:12 2016 +0200 $ Plugins: 201609151123 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ CoInterpreter VMMaker.oscog-eem.1950 uuid: b4089b49-1494-49d2-8966-57cba5c92194 Sep 15 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1950 uuid: b4089b49-1494-49d2-8966-57cba5c92194 Sep 15 2016 Levente On Sun, 2 Apr 2017, David T. Lewis wrote: > I think I'm getting myself confused with too many images with different > DateAndTime flavors. We already have primitiveLocalMicrosecondClock that > can be called with primLocalMicrosecondClock, which hopefully does the > same thing as my snippet below. > > Dave > > > On Sun, Apr 02, 2017 at 10:48:00AM -0400, David T. Lewis wrote: >> Or do it like this, which does not require LocalePlugin: >> >> localMicrosecondClockDave >> | timeArray | >> timeArray := self primPosixMicrosecondClockWithOffset. >> ^timeArray first + ((2177452800 + timeArray second) * 1000000). >> >> Dave >> >> >> On Sun, Apr 02, 2017 at 02:08:07PM +0200, Levente Uzonyi wrote: >> > Hi Herbert, >> > >> > This issue was discussed[1] here recently. I suggested[2] a VM change to >> > solve this problem, but the same thing can be done on the image side too. >> > Just change Time class >> #utcMicrosecondClockWithOffset to be: >> > >> > utcMicrosecondClockWithOffset >> > "Answer an array with UTC microseconds since the Smalltalk epoch and >> > the >> > current seconds offset from UTC in the local time zone." >> > >> > | utc currentMinute | >> > utc := self utcMicrosecondClock. >> > currentMinute := utc // 60000000. >> > LastTimeTimeZoneWasUpdated = currentMinute ifFalse: [ >> > LastTimeTimeZoneWasUpdated := currentMinute. >> > TimeZoneOffset := Locale current primTimezone * 60 ]. >> > ^{ utc. TimeZoneOffset } >> > >> > and Time class >> #localMicrosecondClock to be: >> > >> > localMicrosecondClock >> > "Answer the local microseconds since the Smalltalk epoch (January >> > 1st 1901, the start of the 20th century). >> > The value is derived from the current UTC wallclock time and the >> > image's current notion of time zone." >> > >> > | utcMicrosecondClockWithOffset | >> > utcMicrosecondClockWithOffset := self utcMicrosecondClockWithOffset. >> > ^(utcMicrosecondClockWithOffset at: 2) * 1000000 + >> > (utcMicrosecondClockWithOffset at: 1) >> > >> > >> > LastTimeTimeZoneWasUpdated and TimeZoneOffset should be class variables. >> > They don't have to be initialized. >> > >> > Levente >> > >> > [1] >> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193594.html >> > [2] >> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193638.html >> > >> > On Sun, 2 Apr 2017, Herbert K?nig wrote: >> > >> > >Hi all, >> > > >> > >I have a long running 5.1 image on a Raspi A+ which regularly waits on a >> > >Delay. >> > > >> > >Raspbian has noticed daylight saving, Squeak not. >> > > >> > >Is this expected and what can I do with the running image to make it >> > >notice? Except waiting for the monthly crash and restart :-) >> > > >> > > >> > >Cheers, >> > > >> > >Herbert >> > > >> > > >> > > >> >> > >> >> |
Re: Should a long running image notice daylight saving?
|
|
Another interesting aspect of timezone changes is what along running application should do, once we have the time corrected. Consider a graph of the last 7 days’ rainfall with an X axis labelled by the hour. Should the labels be redrawn with the revised TZ? Or the old ones kept as-was and only new ones changed? Does it make more sense to see
8:00 9:00 10:00 11:00 12:00 12:00 1:00 ie with the change visible, rather than all the older data getting changed? I really can't decide, so if anyone knows of UI/perceptual psych work offering a good rationale I’d be interested. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim A)bort, R)etry, I)gnore, V)alium? |
Re: Should a long running image notice daylight saving?
|
|
In reply to this post by Levente Uzonyi
Hi Levente,
> On Apr 2, 2017, at 11:46 AM, Levente Uzonyi <[hidden email]> wrote: > > Hi Dave, > > As I mentioned before, the problem with that primitive is that it doesn't update the offset when the time zone changes. Surely it would be easy to modify the heartbeat and/or the event checking code in the vm to do thus no? My only questions are a) is this a better place than do it than in the image? and b) who is volunteering to write and test the code? > Here's an example from an image which was started in UTC+1, but is in UTC+2 right now: > > { Time primPosixMicrosecondClockWithOffset. Locale current primTimezone } "#(#(1491158588541139 3600) 120)" > > VM info: > /squeak/products/cogspur64linuxht/lib/squeak/5.0-201609151123/squeak > Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.1950] > Unix built on Sep 15 2016 11:24:50 Compiler: 4.6.3 > platform sources revision VM: 201609151123 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Sep 15 13:23:12 2016 +0200 $ Plugins: 201609151123 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > CoInterpreter VMMaker.oscog-eem.1950 uuid: b4089b49-1494-49d2-8966-57cba5c92194 Sep 15 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1950 uuid: b4089b49-1494-49d2-8966-57cba5c92194 Sep 15 2016 Why are you used my such an ancient vm? You know the new compactor tie appears that be fixed right? [add smileys to taste; I do not intend to offend here] > > Levente > >> On Sun, 2 Apr 2017, David T. Lewis wrote: >> >> I think I'm getting myself confused with too many images with different >> DateAndTime flavors. We already have primitiveLocalMicrosecondClock that >> can be called with primLocalMicrosecondClock, which hopefully does the >> same thing as my snippet below. >> >> Dave >> >> >>> On Sun, Apr 02, 2017 at 10:48:00AM -0400, David T. Lewis wrote: >>> Or do it like this, which does not require LocalePlugin: >>> >>> localMicrosecondClockDave >>> | timeArray | >>> timeArray := self primPosixMicrosecondClockWithOffset. >>> ^timeArray first + ((2177452800 + timeArray second) * 1000000). >>> Dave >>> On Sun, Apr 02, 2017 at 02:08:07PM +0200, Levente Uzonyi wrote: >>> > Hi Herbert, >>> > > This issue was discussed[1] here recently. I suggested[2] a VM change to > solve this problem, but the same thing can be done on the image side too. >>> > Just change Time class >> #utcMicrosecondClockWithOffset to be: >>> > > utcMicrosecondClockWithOffset >>> > "Answer an array with UTC microseconds since the Smalltalk epoch and > the >>> > current seconds offset from UTC in the local time zone." >>> > > | utc currentMinute | >>> > utc := self utcMicrosecondClock. >>> > currentMinute := utc // 60000000. >>> > LastTimeTimeZoneWasUpdated = currentMinute ifFalse: [ >>> > LastTimeTimeZoneWasUpdated := currentMinute. >>> > TimeZoneOffset := Locale current primTimezone * 60 ]. >>> > ^{ utc. TimeZoneOffset } >>> > > and Time class >> #localMicrosecondClock to be: >>> > > localMicrosecondClock >>> > "Answer the local microseconds since the Smalltalk epoch (January > 1st 1901, the start of the 20th century). >>> > The value is derived from the current UTC wallclock time and the > image's current notion of time zone." >>> > > | utcMicrosecondClockWithOffset | >>> > utcMicrosecondClockWithOffset := self utcMicrosecondClockWithOffset. >>> > ^(utcMicrosecondClockWithOffset at: 2) * 1000000 + > (utcMicrosecondClockWithOffset at: 1) >>> > > > LastTimeTimeZoneWasUpdated and TimeZoneOffset should be class variables. > They don't have to be initialized. >>> > > Levente >>> > > [1] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193594.html >>> > [2] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193638.html >>> > > On Sun, 2 Apr 2017, Herbert K?nig wrote: >>> > > >Hi all, >>> > > >>> > >I have a long running 5.1 image on a Raspi A+ which regularly waits on a > >Delay. >>> > > >>> > >Raspbian has noticed daylight saving, Squeak not. >>> > > >>> > >Is this expected and what can I do with the running image to make it > >notice? Except waiting for the monthly crash and restart :-) >>> > > >>> > > >>> > >Cheers, >>> > > >>> > >Herbert >>> > > >>> > > >>> > > >>> > > |
Re: Should a long running image notice daylight saving?
|
|
In reply to this post by timrowledge
Hi Tim,
> On Apr 2, 2017, at 2:11 PM, tim Rowledge <[hidden email]> wrote: > > Another interesting aspect of timezone changes is what along running application should do, once we have the time corrected. Consider a graph of the last 7 days’ rainfall with an X axis labelled by the hour. Should the labels be redrawn with the revised TZ? Or the old ones kept as-was and only new ones changed? Does it make more sense to see > 8:00 9:00 10:00 11:00 12:00 12:00 1:00 > ie with the change visible, rather than all the older data getting changed? I really can't decide, so if anyone knows of UI/perceptual psych work offering a good rationale I’d be interested. is this really complicated? a) UTC is unaffected by timeline so there is a monotonically increasing clock b) the difference in intent between Delay forSeconds: and something like Delay until: should be clear. One is a duration, the other takes some time stamp. The time stamp can convey the time zone or its absence and so the utc for the expiry should be determinable no? > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > A)bort, R)etry, I)gnore, V)alium? > > > |
|
|
In reply to this post by timrowledge
On Mon, Apr 3, 2017 at 5:11 AM, tim Rowledge <[hidden email]> wrote: Another interesting aspect of timezone changes is what along running application should do, once we have the time corrected. Consider a graph of the last 7 days’ rainfall with an X axis labelled by the hour. Should the labels be redrawn with the revised TZ? Or the old ones kept as-was and only new ones changed? Does it make more sense to see 08:00[GMT-8] 09:00[GMT-8] 10:00[GMT-8] 11:00[GMT-8] 12:00[GMT-8] 12:00[GMT-9] 01:00[GMT-9] or more succinctly... 08:00[-8] 09:00[-8] 10:00[-8] 11:00[-8] 12:00[-8] 12:00[-9] 01:00[-9] cheers -ben Pragmatic engineering: If you can't solve the problem, change the problem. ie with the change visible, rather than all the older data getting changed? I really can't decide, so if anyone knows of UI/perceptual psych work offering a good rationale I’d be interested. |
Re: [Vm-dev] Should a long running image notice daylight saving?
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot,
On Sun, 2 Apr 2017, Eliot Miranda wrote: > > Hi Levente, > >> On Apr 2, 2017, at 11:46 AM, Levente Uzonyi <[hidden email]> wrote: >> >> Hi Dave, >> >> As I mentioned before, the problem with that primitive is that it doesn't update the offset when the time zone changes. > > Surely it would be easy to modify the heartbeat and/or the event checking code in the vm to do thus no? My only questions are a) is this a better place than do it than in the image? and b) who is volunteering to write and test the code? I still think that the mechanism I described in this thread (and the previous thread) should be implemented in primitive 241 and primitiveUtcWithOffset unless there's an event-based mechanism provided by the OS. > >> Here's an example from an image which was started in UTC+1, but is in UTC+2 right now: >> >> { Time primPosixMicrosecondClockWithOffset. Locale current primTimezone } "#(#(1491158588541139 3600) 120)" >> >> VM info: >> /squeak/products/cogspur64linuxht/lib/squeak/5.0-201609151123/squeak >> Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.1950] >> Unix built on Sep 15 2016 11:24:50 Compiler: 4.6.3 >> platform sources revision VM: 201609151123 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Sep 15 13:23:12 2016 +0200 $ Plugins: 201609151123 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> CoInterpreter VMMaker.oscog-eem.1950 uuid: b4089b49-1494-49d2-8966-57cba5c92194 Sep 15 2016 >> StackToRegisterMappingCogit VMMaker.oscog-eem.1950 uuid: b4089b49-1494-49d2-8966-57cba5c92194 Sep 15 2016 > > Why are you used my such an ancient vm? You know the new compactor tie appears that be fixed right? It's running on a server, and it works, so I'd rather not restart it. Levente > > [add smileys to taste; I do not intend to offend here] >> >> Levente >> >>> On Sun, 2 Apr 2017, David T. Lewis wrote: >>> >>> I think I'm getting myself confused with too many images with different >>> DateAndTime flavors. We already have primitiveLocalMicrosecondClock that >>> can be called with primLocalMicrosecondClock, which hopefully does the >>> same thing as my snippet below. >>> >>> Dave >>> >>> >>>> On Sun, Apr 02, 2017 at 10:48:00AM -0400, David T. Lewis wrote: >>>> Or do it like this, which does not require LocalePlugin: >>>> >>>> localMicrosecondClockDave >>>> | timeArray | >>>> timeArray := self primPosixMicrosecondClockWithOffset. >>>> ^timeArray first + ((2177452800 + timeArray second) * 1000000). >>>> Dave >>>> On Sun, Apr 02, 2017 at 02:08:07PM +0200, Levente Uzonyi wrote: >>>> > Hi Herbert, >>>> > > This issue was discussed[1] here recently. I suggested[2] a VM change to > solve this problem, but the same thing can be done on the image side too. >>>> > Just change Time class >> #utcMicrosecondClockWithOffset to be: >>>> > > utcMicrosecondClockWithOffset >>>> > "Answer an array with UTC microseconds since the Smalltalk epoch and > the >>>> > current seconds offset from UTC in the local time zone." >>>> > > | utc currentMinute | >>>> > utc := self utcMicrosecondClock. >>>> > currentMinute := utc // 60000000. >>>> > LastTimeTimeZoneWasUpdated = currentMinute ifFalse: [ >>>> > LastTimeTimeZoneWasUpdated := currentMinute. >>>> > TimeZoneOffset := Locale current primTimezone * 60 ]. >>>> > ^{ utc. TimeZoneOffset } >>>> > > and Time class >> #localMicrosecondClock to be: >>>> > > localMicrosecondClock >>>> > "Answer the local microseconds since the Smalltalk epoch (January > 1st 1901, the start of the 20th century). >>>> > The value is derived from the current UTC wallclock time and the > image's current notion of time zone." >>>> > > | utcMicrosecondClockWithOffset | >>>> > utcMicrosecondClockWithOffset := self utcMicrosecondClockWithOffset. >>>> > ^(utcMicrosecondClockWithOffset at: 2) * 1000000 + > (utcMicrosecondClockWithOffset at: 1) >>>> > > > LastTimeTimeZoneWasUpdated and TimeZoneOffset should be class variables. > They don't have to be initialized. >>>> > > Levente >>>> > > [1] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193594.html >>>> > [2] > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193638.html >>>> > > On Sun, 2 Apr 2017, Herbert K?nig wrote: >>>> > > >Hi all, >>>> > > >>>> > >I have a long running 5.1 image on a Raspi A+ which regularly waits on a > >Delay. >>>> > > >>>> > >Raspbian has noticed daylight saving, Squeak not. >>>> > > >>>> > >Is this expected and what can I do with the running image to make it > >notice? Except waiting for the monthly crash and restart :-) >>>> > > >>>> > > >>>> > >Cheers, >>>> > > >>>> > >Herbert >>>> > > >>>> > > >>>> > > >>>> > >> |
Re: Should a long running image notice daylight saving?
|
|
In reply to this post by Eliot Miranda-2
> On 02-04-2017, at 8:44 PM, Eliot Miranda <[hidden email]> wrote: > > is this really complicated? It depends very heavily on the audience the graph is aimed at. Changing to/from DST is fraught enough I guess, maybe the answer for general consumption is just to fudge it out? > > a) UTC is unaffected by timeline so there is a monotonically increasing clock > b) the difference in intent between > Delay forSeconds: > and something like > Delay until: > should be clear. One is a duration, the other takes some time stamp. The time stamp can convey the time zone or its absence and so the utc for the expiry should be determinable no? There y’go, being all experty again. Haven’t we learnt that Real People just want Simple Answers? Such a pity reality isn’t like that. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Klingon Code Warrior:- 3) "Perhaps it IS a good day to Die! I say we ship it!" |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |