We all know there are are many use-cases, and a couple of ways to
interpret things with TimeZones.  Maybe we need to add a clarifying
comment somewhere.  Just because you think about things a particular
way does not make the other ways "horrible" or not "sane".  All this
hyperbole does not help anyone understand what you think is wrong with
Chronology.  I'm certainly not going to let it be the basis for
breaking legacy apps which have been working for years.  Let's talk.
I really didn't want to open this can of worms, but if we have to, we
have to.

On Thu, Feb 18, 2016 at 1:45 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
>> On 18.02.2016, at 11:18, David T. Lewis <lewis at mail.msen.com> wrote:
>>
>>> On 18.02.2016, at 09:30, David T. Lewis <lewis at mail.msen.com> wrote:
>>>>
>>>> I guess it has been nearly two years since I did that project. Time
>>>> flies.
>>>>
>>>> We discussed it on the list in thread "A UTC based implementation of
>>>> DateAndTime":
>>>>
>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-May/178325.html
>>>>
>>>> But I'm not asking you to review that project, I just wanted to suggest
>>>> giving Chronology its own package so that it would be possible to do
>>>> things like this. For my purposes, I can always use a SAR. But it would
>>>> be
>>>> a lot nicer to be able to use Monticello.
>>>
>>> Why wouldn’t it work to submit a new Kernel package to inbox? Migration
>>> issue?
>>>
>>
>> Yes, migration issues. The updates have to be done in steps, with old
>> instances becomed into new at two points in the update process (in package
>> preambles or postscripts). I can make it work at any given point, but a
>> month later Kernel will have progressed, and I have to start over again.
>>
>> Dave
>
> Okay. If this is a chance to get more sane date/time handling, I’m all for it :)
>
> - Bert -
>
>
>
>
>
>