> On 9 Apr 2018, at 17:34, Aliaksei Syrel <alex.sy...@gmail.com> wrote:
> 
> Must watch :)
> 
> The Problem with Time & Timezones - Computerphile
> https://www.youtube.com/watch?v=-5wpm-gesOY

Haha, that is indeed hilarious. 

I guess there is no complete, absolute 100% correct answer for all use cases, 
we can only try to be reasonably good.

> On 9 April 2018 at 17:26, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> 
> 
> > On 9 Apr 2018, at 15:19, Sean P. DeNigris <s...@clipperadams.com> 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
> >
> 
> 
> 


Reply via email to