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.
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.
> 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.
> '1/1/1990' asDate.
> 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).
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html