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.

- 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.

Would anyone object to this change to package structure?

Thanks,
Dave


On Wed, Feb 17, 2016 at 05:13:05PM -0800, tim Rowledge wrote:
> We can see the primitives involved with this do it -
>  {SystemNavigation default browseMessageList: #(
> 'Time class primMicrosecondClock 117' 
> 'Time class primMillisecondClock 135??? 
> 'Time class eventMillisecondClock 135??? 
> 'Time class primPosixMicrosecondClockWithOffset 117??? 
> 'Time class primUTCMicrosecondClock 240??? 
> 'Time class localMicrosecondClock 241??? 
> 'Time class utcMicrosecondClock 240??? 
> 'Time class primSecondsClock 137??? 
> 'Time class primMillisecondClockMask 117??? 
> 'Time class primLocalMicrosecondClock 241') name: 'time prims???}
> 
> a) primMicrosecondClock is not sent in a 5.0 image and seems to only be implemented in a plain interpreter VM.
> b) primMillisecondClock/135 is not sent in a 5.0 image
> c) eventMillisecondClock/135 is used for the faked-up events required for double-click handling
> d) primPosixMicrosecondClockWithOffset is not sent in 5.0
> e) primUTCMicrosecondClock/240 is not sent in 5.0 - would return uSec value in raw
> f) localMicrosecondClock/241 is used in 5.0 in particular from Time now (as per the ClockMorph)
> g) utcMicrosecondClock/240 is used in 5.0 for Delays and timing type cases
> h) primSecondsClock/137 isn???t used in 5.0
> i) primMillisecondClockMask isn???t used in 5.0
> j) primLocalMicrosecondClock/241 isn???t used in 5.0
> 
> So we have quite a collection of mixedup terminology and unused methods to clear up!
> 
> Looking at it from the prims point of view -
> 
> Prim 135 is needed in order to provide the same timebase as the events coming in, so we can???t drop that, and it affects nothing else.
> 
> Prim 240 is for no-TZ microseconds and is used in Delay etc but crucially as part of DateAndTime>now which is why we are having a problem in the latest updated 5.0 with no TZ/Locale being used.
> Prim 241 is used by Time now etc and includes the TZ offset, which is why Time now returns correct wall-clock time.
> 
> The others are no longer used and could be removed except for the primPosixMicrosecondClockWithOffset which we ought to make use of so that the TZ is reported back.
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful Latin Phrases:- Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? = How much wood would a woodchuck chuck if a woodchuck could chuck wood?
> 
>