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