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.

> 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.

>>> 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.

>
> On 2013-02-01, at 10:33, Otto Behrens <[hidden email]> 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 <[hidden email]> wrote:
>>
>> On 2013-02-01, at 10:33, Otto Behrens <[hidden email]> 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
>>>
>>
>>
>