[squeak-dev] Move Chronology out of Kernel and into its own Chronology package (was: trunk thinks its tomorrow)

David T. Lewis lewis at mail.msen.com
Thu Feb 18 17:30:57 UTC 2016

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


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.


> I read it, it tells me _what_ it is; a different internal
> representation for the Chronology classes, but I could not put
> together the why, as a user, I should want to use it.  This is not a
> criticism, Dave, just ignorance.  What's are the pros and cons of
> UTCDateAndTime approach?
> On Thu, Feb 18, 2016 at 10:51 AM, David T. Lewis <lewis at mail.msen.com>
> wrote:
>> Hi Chris,
>> This was something I did last year:
>>   http://wiki.squeak.org/squeak/6197
>> I would like to be able to share this so folks can review the code. I'd
>> prefer to be able to do that with Monticello, which is not practical
>> with
>> the current package structure.
>> Dave
>>> On Wed, Feb 17, 2016 at 7:33 PM, David T. Lewis <lewis at mail.msen.com>
>>> wrote:
>>>> I would like to move Chronology from 'Kernel-Chronology' to a new
>>>> package
>>>> called 'Chronology', and move 'KernelTests-Chronology' to a new
>>>> package
>>>> called 'Tests-Chronology'.
>>>> Rationale:
>>>> - Chronology is a large package that is functionally separable from
>>>> the
>>>> rest of the things in Kernel.
>>> It's not that big.  It includes Date and Time, which are part of base
>>> Smalltalk-80.  How you going to extricate those from Chronology?
>>>> - I have a UTC based variation of Chronology that addresses a number
>>>> of
>>>> issues that I think may be of long term benefit, and that prevent the
>>>> kinds
>>>> of issues that we are currently seeing in trunk. I would like to offer
>>>> this
>>>> for review in the inbox, but that is not practical with the current
>>>> packaging.
>>> Chronology has proved its usefulness in a wide variety of
>>> applications.  I have no issues with it.  What issues are you
>>> attempting to address with your UTC based variation?
>>>> Would anyone object to this change to package structure?
>>> I really think Date and Time and possibly even DateAndTime are part of
>>> Kernel Smalltalk-80.  I think it would be nice to know what it is
>>> you're really trying to accomplish with your UTC variation..
>>> Incidentally, if you do go down this road, the standard that most
>>> packages following these days are hierarchical names; Chronology-Core
>>> and Chronology-Tests.

More information about the Squeak-dev mailing list