Hi Sven I'm totally stupid on this topic now I was retrospectively thinking about the situation already some years ago. We tried to enhance the old core back when we were still in Squeak and now I would do the opposite.
I would make sure that the core is only working for the pharo logic (and use the minimal set of abstractions covering only the minimum for pharo core) and provide a good library for other cases. What you think? Alternatively we could have Date -> SimpleDate and add ZTimezone. Last time I played with Date and Span I got confused (It was for automatically issuing bills each month) and I realised that the abstractions we have are clunky or may be I did not use them. I wanted to have a month in a year (for example to get the 29 or 28 automatically and I had to do all kind of tricks. Stef On Mon, Apr 9, 2018 at 5:26 PM, 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 >> > >
