[squeak-dev] About the new Date

Chris Muller ma.chris.m at gmail.com
Sun Feb 5 20:27:38 UTC 2012


On Sun, Feb 5, 2012 at 1:23 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 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.

I was very surprised too.

> 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 problems it creates are deeper than that.

For your manufacturing system, you just wanted the resolution of a
Date; not its start time.  I don't know about the system, but for sake
of illustration, I want to say it's a large system involving multiple
machines providing input to the system.

Now, imagine, one day, one machine in the system goes out for repair
-- maybe it got its clock-battery replaced.  It comes back on-line
thinking it's in a different time-zone.

Your manufacturing system does "Date today + 7 days" or maybe it just
parses a date string:  '2/15/2012' asDate.

Your system is now being silently polluted with Dates that will not
compare to the "productionDate" and the company misses a schedule.

It's not about the number of people affected, it's the severity of the
punishment to a system that never cared about timezone-sensitive Dates
-- and shouldn't be required to unless it wants that.

> 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

I'm sorry -- I forgot to tell everyone:  After loading, please run the
following expression:

      TimeZone withAllSubclassesDo: [ : each | each initialize ]

I should have put that as a postscript..

After that you should not have any breakages except in TimeStamp
because we want to purge that, not work on it.

 - Chris


More information about the Squeak-dev mailing list