Must watch :) The Problem with Time & Timezones - Computerphile https://www.youtube.com/watch?v=-5wpm-gesOY
On 9 April 2018 at 17:26, Sven Van Caekenberghe <[email protected]> wrote: > > > > On 9 Apr 2018, at 15:19, Sean P. DeNigris <[email protected]> wrote: > > > > Max Leske wrote > >> Assuming UTC is probably just as wrong as assuming the local time zone. > > > > I'll modify your statement slightly. "Assuming UTC is */almost/* as > wrong as > > assuming the local time zone." > > > > I've never seemed to be able to drive the essential point home when these > > discussions have come up. Beyond all the wider issues, there is a bug, > plain > > and simple: The offset of `'1/1/1990' asDate`, considering that you mean > > local time, is still not guaranteed to be the current local offset of the > > image, which is how we set it by default. That only makes sense if the > > historical date in question was in the same state of DST as the current > > image. For example, the historical date above is in winter, so if I eval > > that code in summer, it will /always/ give the objectively wrong offset. > > > > What I'm proposing is not a cure all, but a slightly-better way that > fixes > > this bug by giving users consistent behavior that they may not want > instead > > of inconsistent and often wrong behavior that they may not want. > > Sean, > > You are right, the current system cannot be fixed. It only knows about the > current timezone's offset (via the OS), not about historical offsets. And > it wrongly uses that offset because it does not know better. > > Neither > > '1/1/1990' asDate. > > nor > > Date today. > > can work without the context of a precise timezone. It is even relatively > pointless to remember offsets without remembering timezones. You simply > need a precise reference into the transitions database. > > New York is 5 hours behind UTC in winter. > > Question 1: When (in absolute UTC time) was the beginning of the 1st day > of January in 1990 in New York's local time, when we express the date in > UTC ? > > (ZTimezone id: 'America/New_York') gmtToLocal: (ZTimestamp @ '1990/01/01'). > > => "1989-12-31T19:00:00Z" > > So when the UTC day of January 1st 1990 starts, New York local time is > still 5 hours behind. > > Question 2: When (in absolute UTC time) was the beginning of the 1st day > of January in 1990 in UTC time, when we express the date locally ? > > (ZTimezone id: 'America/New_York') localToGmt: (ZTimestamp @ '1990/01/01'). > > => "1990-01-01T05:00:00Z" > > So when the New York day of January 1st 1990 starts, UTC time is already 5 > hours ahead. > > Note that the question 'When does January 1st 1990 start in any timezone, > when expressed in that timezone, is of course a constant, midnight'. > > > I think that making Date always UTC will probably not help, because you > will want to be able to move between timezones. I guess the only solution > is to add a class like ZTimezone (which has no dependencies). > > > Sven > > > ----- > > Cheers, > > Sean > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > > > > >
