On Sun, Feb 05, 2012 at 11:56:06AM -0600, Chris Muller wrote:
> 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.

Thanks for sending the MA time objects attachments. I would have
expected a performance gain from wrapping a single LargeInteger, very
interesting that it did not make a measurable difference.

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

I don't mean to say that it's horribly broken, just broken for cases
involving durations that span daylight savings time transitions, leap
seconds, and that sort of thing. This is not a good thing, but in
practice it seems to affect a relatively small number of people. I'm
not saying that is good, but it's not entirely horrible either, and
making it better is difficult.

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

I'm definitely looking at your inbox solution and have it loaded in
an image to experiment. Maybe I'm doing something wrong, but I get a
lot of test failures and errors, see attached. I'm running on Linux
with Cog, my computers' time zone is set for America/Detroit, and
the Squeak timezone is set to a TimeZone(UTC). I have my TimeZoneDatabase
package loaded also, but I force-loaded trunk/Kernel-eem.668 followed
by inbox/Kernel-cmm.669 to make sure everything was consistent, and I
evaluated "DateAndTime localTimeZone: TimeZone default" before running
the tests. Are you seeing different results?

My other concern as previously noted is that it does not seem to me
to make logical sense to have "Date today" answer a duration with a
start time of yesterday at 5 hours before midnight. Maybe that is not
important in practice but it does not feel right to me.

Please note that I do not mean to be casting a veto here. If there
is general concensus that your inbox approach is a good thing, then
you will have my full support.

> 
> 
> 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: Test Runner.2.png
Type: image/png
Size: 48456 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120205/94b9e6d6/TestRunner.2.png