The Timing of Time

Alan Lovejoy squeak-dev.sourcery at forum-mail.net
Fri Apr 14 03:50:04 UTC 2006


Brent wrote: "I like your work."

Thanks.

I think Chronology was a valuable and worthwhile contribution to Squeak, in
spite of the fact that it hasn't pleased everyone. I don't suppose
everyone's happy with Chronos, either.  And I know there are those who think
the whole subject is insufferably boring, based on the non-reaction that
posts about dates and times typically receive (David T. Lewis nods his head)
:-)

Brent: "frustration with existing date libraries"

Heh. You too?

Brent: "[Chronology] can be made a faster at the expense of adding some more
code"

Ayup.  Faster, better, cheaper (=smaller): choose any two :-)

Brent: "I unfortunatley live in a country with one timezone and no daylight
savings policy. As such I have very little _real_ understanding of the
subtleties."

Actually, even programmers (let alone lay people) who live near the borders
between time zones, and have had to deal with DST all their lives, typically
don't understand how to do time zones correctly.  The human mind wants time
to be an invariant, the laws of man and of physics notwithstanding.

Brent: "One advantage is that Chronology does not require and external files
which stays true to the All-In-The-Image tradition."

To load all the offset transition rules for all the time zones in the Olson
Time Zone Database into the image requires more than a megabyte.

Olson issues an updated version of his database about once a month--some
years, more often than that.  There's always some non-trivial number of
countries, regions, counties or cities that decide to change their time zone
rules each year.  Some locales decide de novo each year when (or perhaps
whether) they will transition to/from DST. Election results may mean DST
starts or stops being observed. So hard-coding the rules would require
updating the code in the image on a regular basis.  Storing the rules in the
image as data would take up a lot of memory (as would storing all the rules
as code, for that matter,) and would still require some mechanism for
updating the data in the image--which effectively leads you to something
resembling what Chronos does: storing the zone rules as external reference
data, but using a WeakValueDictionary to ensure that there's never more than
one instance of "the same" time zone in the image.

Actually, a simple modification to Chronos would enable any or all Olson
time zones to be stored in the image via strong references.  Also, I
recently implemented the ability to fetch Olson time zone rules one at a
time, on demand, over HTTP (as far as I know, no other date/time library in
the world has such a capability.)  And Chronos does not absolutely require
the Olson time zones.  You can either a) use BasicTimezone instances (which
have essentially the same functional characteristics as Chronology's
TimeZones do,) or b)programmatically create "in memory only" instances of
VariableOffsetTimezone, as many or as few as you need, with rulesets as
simple or as complex as may be required.

Brent: "Enjoy Easter"

And I hope you enjoy Good Friday

--Alan

-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of Brent
Pinkney
Sent: Thursday, April 13, 2006 12:37 AM
To: The general-purpose Squeak developers list
Subject: Re: The Timing of Time

Hi Alan,

I like your work. Here is some backgroun on Chronology:

I wrote the original Chronology library based on frustration with existing
date libraries - I recall counting that Java had no less than six classes to
represent a date.

The project I have been working on required iterating over a lot of date
intervals. The poor date models on offer caused a lot of 'off by one'
errors.

I liked the ANSI protocol but wanted to bring the #do: #collect:, etc
methods to bear on date/time intervals. Someone prior to me had already
implemented Week and Month in Squeak which was the trigger I needed to
implement Chronology.

I also decided to implement the DateAndTime class as a julian day + offset
from midnight + offset from UTC.

Chronology is a bit heavy handed as it assumes nano second precision for all
operations. This makes the implementation clean and the library quite
powerful, but it is slower. It can be made a faster at the expense of adding
some more code but so far the penalty is not noticable.

Although Chronology does support TimeZones, its support is still quite
limited. I unfortunatley live in a country with one timezone and no daylight
savings policy. As such I have very little _real_ understanding of the
subtleties. The scaffolding it there though.

One advantage is that Chronology does not require and external files which
stays true to the All-In-The-Image tradition.

Enjoy Easter

Brent





> Hi!
>
> "Alan Lovejoy" <squeak-dev.sourcery at forum-mail.net> wrote:
> > Since some of you seem to like benchmarks, you might be interested
> >in my  recent blog post, where I present benchmars comparing the
> >Squeak version  of Chronos to Squeak's native Chronology package:
> >
http://chronos-st.blogspot.com/2006/04/timing-of-time-chronos-benchmarks.
> >html
> >
> > --Alan
>
> Impressive. I also read your page about the Squeak version - really
> informative and impressive too.
>
> So... what is your opinion on what we should do to make the choice easy?
> I noticed you wrote about convenience methods etc.
>
> In an ideal world we would be able to just "pick and choose" between
> Chronology and Chronos, but I simply don't have enough knowledge to
> judge the feasibility and/or work involved to make that a reality.
>
> regards, Göran
>
> PS. But I do think the official Squeak should make a choice - there
> should be a "Squeak standard". And of course, we did that pretty
> recently - Chronology. Would be interesting to hear more about
> pros/cons. :)





More information about the Squeak-dev mailing list