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@freudenbergs.de wrote:
On 18.02.2016, at 11:18, David T. Lewis lewis@mail.msen.com wrote:
On 18.02.2016, at 09:30, David T. Lewis lewis@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 -