hi guys

What I think that we should do is the following:
You decide, collect, run the tests and once this is done you ping,  
publish the new package to be integrated in
the inbox of the squeakfoundation and I integrated as the first new  
package of 3.10.


Now recently I was thinking that retrospectively it would have been  
better to keep a really small
and limited core class (that the system only requires) and have  
separate and loadable time packages.
I have the impression that aconcagua for example is circuventing some  
limits of Brent packages...
So having packages that are not tied to the kernel would make their  
evolution/tests/maintenance
easier. What do you think about that?

Stef


On 31 août 06, at 14:22, Brent Pinkney wrote:

> Hi,
>
> From the Mantis issue:
> I am nominally responsible for the Chronology package since I wrote  
> it :)
>
> I have tested and reviewed this change. All tests pass in 3.8.1  
> (6744).
>
> I would also encourage this enhancement to include Dan Ingall's  
> modificaton
> which significantly speeds up printing a DateAndTime instance.
>
> All tests work with both enhancements.
> I have attached my cleanup of Dan's code to this issue.
>
>      suite := TestSuite new name: 'Chronology Tests'.
>      (SystemOrganization superclassOrder: #'Kernel-Chronology-Tests')
>          do: [ :tc | tc addToSuiteFromSelectors: suite ].
>      suite run.
>
> RESULT: 420 run, 420 passes, 0 expected failures, 0 failures, 0  
> errors...
>
> I strongly encourage both changesets to be approved.
>
> ---------------------------------------------------------------------- 
> -----------------------------------------
>> It would be nice if someone could summarize all Time related
>> classes and when to use which one. There is plenty of them these  
>> days.
>
> I developed the Chronology class to precisely solve the problem of  
> many Time classes.
> If you read the original wiki page (http://minnow.cc.gatech.edu/ 
> squeak/1871) I refer to
> my experience with Java/J++ where there were 6 different class  
> libraries to choose from.
>
> I added the support for nano second precision precisely to future- 
> proof the design.
>
>> For example, Date as you mention seems IMHO also like it still  
>> could be
>> stored as a julian day number. A "Date beast" with duration etc seems
>> like it probably could be called a Day instead.
>
> Perhaps, but a Date definately starts at midnight and ends 86400  
> later. So it
> has a duration. I chose Date as Day implies the sun is shining :)
>
>> A Date does not in my mind represent a "specific historic period",  
>> but I am no expert
>> of course.
>
> If you are interested, the design came from my experience of off-by- 
> one errors when
> manipluating the jail sentences (and other such) things in  
> VisualAge for a certain
> South Pacific nation.
>
> Hence, a given Date occupies all 86400 seconds it legally spans and  
> can be used
> with the other Timespan classes to correctly calculate  
> intersections, etc.
>
>> PS. We also use the Timezone stuff from David Lewis and that also  
>> ties
>> into this using class PointInTime etc. Phew.
>
> David developed his class in isolation - I only learnt of it when  
> he announced it.
>
> Much of the features he offers are related to time zones. The  
> existing chronology
> package does support the basics of time zones with an eye to adding  
> daylight saving
> later.
>
> I did not add that as I live in a country with only one time zone  
> and no daylight saving.
> There is no reason Dave's functionality could not be included.
>
> Brent
>
>