[Pharo-project] daylight savings issues
Hi, We do some calculations based on the number of days elapsed between two dates, by doing (date1 - date2) days * something. If these dates span over a daylight savings switch over, we get one day less, because the duration (result from date1 - date2) has 23 hours (+a number of days). So, do we solve this kind of thing by working with UTC dates only? I read on the mailing list some changes in Pharo 2.0 made by Camiillo and http://forum.world.st/Should-Dates-be-Timezone-specific-td3647678.html. We're not on 2.0 yet and are running on GemStone. Our dates are in a local time zone currently, how do we "work" with UTC dates and make sure the outside world see the correct date / time? How do I write a test for this? Here's an example of such a calculation: returnFromPrice: fromPrice toPrice: toPrice | days | days := (toPrice date - fromPrice date) days. ^ (toPrice value / fromPrice value raisedTo: 365.25 / days) - 1 My issue is that the tests run in an environment without daylight savings. The customer is in a timezone with daylight savings. Thanks Otto
On 2013-02-01, at 09:17, Otto Behrens <otto@finworks.biz> wrote:
Hi,
We do some calculations based on the number of days elapsed between two dates, by doing (date1 - date2) days * something. If these dates span over a daylight savings switch over, we get one day less, because the duration (result from date1 - date2) has 23 hours (+a number of days).
So, do we solve this kind of thing by working with UTC dates only? I read on the mailing list some changes in Pharo 2.0 made by Camiillo and http://forum.world.st/Should-Dates-be-Timezone-specific-td3647678.html.
We're not on 2.0 yet and are running on GemStone. Our dates are in a local time zone currently, how do we "work" with UTC dates and make sure the outside world see the correct date / time?
Most probably you will get away with it, by only displaying dates/times in local time zones, but make sure everything internally uses UTC (without daylight saving times). So you only have to be careful with when inputting data and when displaying. Everything that is relative (like your example) will work out of the box.
How do I write a test for this?
I presume to properly reproduce the problem you would have to change the os system-timezone during a test. Which you could achieve with OSProcess :/
Here's an example of such a calculation:
returnFromPrice: fromPrice toPrice: toPrice | days | days := (toPrice date - fromPrice date) days. ^ (toPrice value / fromPrice value raisedTo: 365.25 / days) - 1
My issue is that the tests run in an environment without daylight savings. The customer is in a timezone with daylight savings.
Thanks Otto
We're not on 2.0 yet and are running on GemStone. Our dates are in a local time zone currently, how do we "work" with UTC dates and make sure the outside world see the correct date / time?
Most probably you will get away with it, by only displaying dates/times in local time zones, but make sure everything internally uses UTC (without daylight saving times).
So you only have to be careful with when inputting data and when displaying. Everything that is relative (like your example) will work out of the box.
This feels painful. I suppose we'll have to hunt for Dates in the system and migrate them. And then change our subclass of MADateDescription (we use a date picker) to convert to & from the local time zone. And then we have a few timestamps, which is indeed time zone sensitive. I feel the need for a timezone agnostic Date. But I suppose working with time and duration may complicate things. Thanks for the help.
How do I write a test for this?
I presume to properly reproduce the problem you would have to change the os system-timezone during a test. Which you could achieve with OSProcess :/
Eeeuw, ok
On 2013-02-01, at 10:33, Otto Behrens <otto@finworks.biz> wrote:
We're not on 2.0 yet and are running on GemStone. Our dates are in a local time zone currently, how do we "work" with UTC dates and make sure the outside world see the correct date / time?
Most probably you will get away with it, by only displaying dates/times in local time zones, but make sure everything internally uses UTC (without daylight saving times).
So you only have to be careful with when inputting data and when displaying. Everything that is relative (like your example) will work out of the box.
This feels painful. I suppose we'll have to hunt for Dates in the system and migrate them. And then change our subclass of MADateDescription (we use a date picker) to convert to & from the local time zone. And then we have a few timestamps, which is indeed time zone sensitive.
Basically everything will work fine until the point your image crosses time-zones. Just be careful ;) I burnt my fingers more than once while fixing this mess :P
I feel the need for a timezone agnostic Date. But I suppose working with time and duration may complicate things.
yeah, we reached that conclusion at the point we tried to fully grasp the scale of the problem. So now we have everything internally in UTC, which simplifies a lot.
Thanks for the help.
How do I write a test for this?
I presume to properly reproduce the problem you would have to change the os system-timezone during a test. Which you could achieve with OSProcess :/
Eeeuw, ok
On 1 February 2013 09:39, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-02-01, at 10:33, Otto Behrens <otto@finworks.biz> wrote:
We're not on 2.0 yet and are running on GemStone. Our dates are in a local time zone currently, how do we "work" with UTC dates and make sure the outside world see the correct date / time?
Most probably you will get away with it, by only displaying dates/times in local time zones, but make sure everything internally uses UTC (without daylight saving times).
So you only have to be careful with when inputting data and when displaying. Everything that is relative (like your example) will work out of the box.
This feels painful. I suppose we'll have to hunt for Dates in the system and migrate them. And then change our subclass of MADateDescription (we use a date picker) to convert to & from the local time zone. And then we have a few timestamps, which is indeed time zone sensitive.
Basically everything will work fine until the point your image crosses time-zones. Just be careful ;) I burnt my fingers more than once while fixing this mess :P
I feel the need for a timezone agnostic Date. But I suppose working with time and duration may complicate things.
yeah, we reached that conclusion at the point we tried to fully grasp the scale of the problem. So now we have everything internally in UTC, which simplifies a lot.
Sticking with UTC everywhere internally, converting local time -> UTC on input, and only displaying local time, is the one true way. All else is madness. frank
Thanks for the help.
How do I write a test for this?
I presume to properly reproduce the problem you would have to change the os system-timezone during a test. Which you could achieve with OSProcess :/
Eeeuw, ok
On 01 Feb 2013, at 10:59, Frank Shearar <frank.shearar@gmail.com> wrote:
On 1 February 2013 09:39, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-02-01, at 10:33, Otto Behrens <otto@finworks.biz> wrote:
We're not on 2.0 yet and are running on GemStone. Our dates are in a local time zone currently, how do we "work" with UTC dates and make sure the outside world see the correct date / time?
Most probably you will get away with it, by only displaying dates/times in local time zones, but make sure everything internally uses UTC (without daylight saving times).
So you only have to be careful with when inputting data and when displaying. Everything that is relative (like your example) will work out of the box.
This feels painful. I suppose we'll have to hunt for Dates in the system and migrate them. And then change our subclass of MADateDescription (we use a date picker) to convert to & from the local time zone. And then we have a few timestamps, which is indeed time zone sensitive.
Basically everything will work fine until the point your image crosses time-zones. Just be careful ;) I burnt my fingers more than once while fixing this mess :P
I feel the need for a timezone agnostic Date. But I suppose working with time and duration may complicate things.
yeah, we reached that conclusion at the point we tried to fully grasp the scale of the problem. So now we have everything internally in UTC, which simplifies a lot.
Sticking with UTC everywhere internally, converting local time -> UTC on input, and only displaying local time, is the one true way. All else is madness.
Yes, indeed the best way. However, that still does not mean that daylight saving does not exist - when it goes in and out of effect, you will see strange things that might confuse or upset end users counting in their local time zone. BTW, there is ZTimestamp in http://mc.stfx.eu/Neo that is a UTC only, second precision DateAndTime/Timestamp that can represent itself in any TZ.
frank
Thanks for the help.
How do I write a test for this?
I presume to properly reproduce the problem you would have to change the os system-timezone during a test. Which you could achieve with OSProcess :/
Eeeuw, ok
participants (4)
-
Camillo Bruni -
Frank Shearar -
Otto Behrens -
Sven Van Caekenberghe