I have no problem if you want move Chronology classes to their own
package (but please do use the "-Core" and "-Tests" suffixes so we
don't suffer the prefix selection problem).  I'll be curious whether
you choose to move Date and Time too..

I'm a heavy user of Chronology, if there's a better version of it, I'm
definitely interested in possibly using it.  I remember that thread;
it helped us identify and fix a performance bug in standard
Chronology.


On Thu, Feb 18, 2016 at 11:30 AM, 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.
>
> Dave
>
>
>> 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.
>>>>
>>>
>>>
>>
>
>