Hi Dave, thanks for the feedback.  However, the yet-another-class
cannot actually satisfy my needs because I also require globalized
Minute, Hour, Month, Quarter and Year timespans.

I totally understand and appreciate what you are saying about having a
"lean Date" a-la Squeak 3.6.  Would you please look at the attached
packages?  This package goes back to 2004, prior to the existence of
Chronology.  It wraps a single LargeInteger to represent any
point-in-time precise to the millisecond.  In fact, observe version 44
of the package even went a step further and, rather than wrapping an
Integer, it even *inherited* from Integer -- e.g., each MaDate WAS an
Integer, with only behaviours.

Guess what:  It didn't perform any better than Chronology's 3
SmallIntegers.  (The benchmark results are published in the version
comments of the attached packages, check it out).

Also, it created unnecessary converting complexities since there are
other areas of the system that use the standard Chronology class.

The other problem is:  If we bring in yet-more-classes, where does
that leave Date, et al?  They're still horribly broken, as you said in
your prior message.  Unsuspecting Squeakers all over the world can be
drastically affected by this.  This is not just my problem, it's
Squeak's problem, and it's a doozie -- wouldn't you say?

The solution in the Inbox addresses all of the practical issues whilst
retaining a single, consistent, coherent and correct implementation of
time-objects for Squeak.  It does not break Chronology.  Dave, I've
been deep down this road and have spent a LOT of time and effort to
address it.  I grok the issues to the core and the solution in the
Inbox addresses them in the safest and smoothest way possible --
without duplication.  Please let us move forward.  I ask you to give
the Inbox solution a try.

  - Chris




Please find, attached, the package "Ma time objects".

> Hi Chris,

> I am leaning towards the "yet another class" approach. In the abstract,
> because I think we are dealing with two different kinds of thing here,
> and that would justify two classes. But in the concrete, and more
> specifically with respect to the Date hash performance problem and
> the time zone problem, here is why:
>
> If I look at what you did in the inbox for Date, you basically are
> normalizing the offset from UTC in specifying the start time of
> date. The duration of the date object is of no interest to you, so
> you could (for your application) get rid of the duration instance
> variable. Now if you look at the start time, it is a DateAndTime
> with all instance variables zeroed out except for jdn. Thus the
> only instance variable data in your Date object that carries any
> useful information is the jdn, which is just a SmallInteger.
>
> This suggests that if you get rid of all the instance variables
> that carry no information, what you are left with is a Date object
> with a single instance variable for julianDayNumber. This would
> be extremely fast and efficient for hashing and comparison, and
> the meaning if this object could be understood with no confusion
> regarding time spans, time zones, or durations. If you could have
> a date object like this, it might very well solve your problems
> with performance and timezone ambiguities.
>
> The interesting thing about this is that the stripped-down date
> object that I am describing here is pretty much exactly the same
> as the Date that was implemented in Squeak prior to Chronology
> (i.e. in Squeak 3.6 and earlier). So if it turns out that the
> Squeak 3.6 implementation of Date solves the performance and
> timezone problems for applications like yours, then I think we
> would be perfectly justified in adding another class to the system.
>
> I work with manufacturing systems in which I run into the concept
> of a "scheduled production date". This sort of date has nothing
> to do with durations, and very little to do with any actual point
> in time. For example, a vehicle may be schedule to be manufactured
> on a production date, and I want to be able to do things like find
> the list of vehicles to be produced on a production date, or identify
> parts and material supplies associated with that production date. But
> I do not care if that "date" is 24 hours in duration, and I do not
> care what hour of the day the scheduled production date begins on.
>
> I don't know if this is similar to the kinds of date you encounter
> in a financial application, but I am envisioning financial transactions
> being associated with a "transaction date" or something of that nature,
> and I suspect this may be similar in some ways to the idea of a
> "scheduled production date". If so, these are things that could be
> very efficiently represented by a date object based on julian day
> number, as opposed to the far more complicated representation of
> date as a DateAndTime with Duration as found in Squeak today.
>
> Dave
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ma time objects-cmm.45.mcz
Type: application/octet-stream
Size: 30447 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120205/af7501be/Matimeobjects-cmm.45-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ma time objects-cmm.44.mcz
Type: application/octet-stream
Size: 30254 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120205/af7501be/Matimeobjects-cmm.44-0001.obj