On 1 February 2013 09:39, Camillo Bruni <[email protected]> wrote: > > On 2013-02-01, at 10:33, Otto Behrens <[email protected]> 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 >> > >
