Goran:

You said: "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."

Yes, that's exactly right.  And it's a much larger issue than just Chronos
vs. Chronology.  Smalltalk historically has not dealt with the issue of
"multiple, possibly-overlapping libraries" well at all--and that may be one
reason it's still on the fringe, and not mainstream. VisualWorks has been
steadily chipping away at this problem; I believe they're still working on
handling all the issues even better than they already do.  David Simmons has
also put some interesting solutions on offer, first in SmalltalkAgents, and
now in S#.

Neither Chronos nor Chronology can lay claim to being the "right standard"
for all programmers, for all use cases or for all situations/environments.
The same is true of other date/time packages, and of all libraries/packages
in general, regardless of domain. For that matter, Smalltalk isn't the right
langauge for everyone all the time, either.  The same goes for English :-).

I know that not everyone agreed, but I was rather impressed by the
"Firewall" technology that ParcPlace was working on back in 1995-96
(brainchild of Allen Wirfs-Brock.)  It's really too bad that project got
dropped pursuant to the ParcPlace meltdown.

Modernly, I think Craig Latta's Spoon project has the most-probably valid
strategic vision in relation to this issue--and I'm not just saying that
because he and I are friends. Spoon is certainly more immediately applicable
to Squeak than either Wirfs-Brock's "Firewall" or Simmons' architectural
concepts would be (although I still think both are worthy of being
leveraged.)

Is Chronos even the right choice as the "standard, out of the box" date/time
package for any Smalltalk?  It's a big library. Loading it adds a megabyte
to a Squeak image. It' intended as an industrial-strength solution for use
cases that need what it can do.  My focus has been on ensuring a) that
Chronos matches or exceeds the functionality, robustness, architectural
elegance and performance of any other date/time library, in any langauge,
and b) that Chronos is portable to any and all Smalltalk implementations,
provided they conform reasonably well to either the "Blue Book" or the ANSI
Standard.  The second goal is responsible more than just trivially for the
size of the Chronos codebase.

So Chronos answers the question "How can I have a rich time model, with
industrial-strength date/time functionality, with an API that is the same
across a variety of Smalltalk implementations?" It does not answer the
question "How can I have a minimal date/time package that just gets me up
and running?"

As technology progresses, memory gets cheaper, and globalization and the
internet bring cross-timezone issues (and/or mult-calendar issues) ever more
to the fore, perhaps a Chronos-scale solution will not only be appropriate,
but "de rigeur" for any programming environment that wants to be considered
a "player." Given what Squeak's primary competitors (e.g, Java) can already
do out of the box, perhaps that time is now, or at least soon.  But this may
well be a "debatable question."

As an alternative, perhaps Brent (or someone else) would be interested in
using the Chronos code as inspiration to refactor Chronology into "Chronos
Lite"--a Gregorian-only, current-year's-zone-offset-transition-rules-only
subset of the Chronos API, using the Chronos logic where and as appropriate
to achieve the desired degree of functionality/performance?

But regardless of the date/time library used (or installed by default,)
Squeak really needs to do something about the issue of discovering the local
time zone from the host operating system (at least in those cases where
Squeak itself isn't the host operating system.)

As for the "convenience methods," those are trivial to implement.  The issue
is that Brent has already implemented most of them using Chronology--which
shows that more than separate class namespaces are needed to handle
inter-package/inter-library conflicts.  Examples of such methods would be
Number>>hours, Number>>minutes, Number>>seconds, Number>>days,
Integer>>weeks, Integer>>months, Integer>>years, BlockClosure>>durationToRun
and String>>asDateAndTime.

--Alan

P.S.

Over the past month, I've put a lot of work into separating out into its own
package much of the inter-Smalltalk portability code used by Chronos.  I've
named this package "Passport."  It provides an abstraction layer that
enables an application to access reference data either from the local disk
or from a remote HTTP server, so the application can do that identically in
any Smalltalk environment to which Passport has been ported.  Currently,
Passport is available for both VisualWorks and Squeak.  A port to Dolphin
will be published soon.

Passport provides the class ResourcePath, which is conceptually a union of a
VisualWorks Filename with a URL object. ResourcePaths support HTTP URLs,
File URLs and native filenames (in the latter case, using native filename
syntax--Windows, Unix or Classic MacOS.) In VisualWorks, they also support
FtpURLs and HttpsURLs (and it wouldn't be all that hard to do the same in
Squeak.)  Note that ResourcePaths can do all that without any
subclasses--they use the Strategy pattern instead.

The Squeak implementation of Passport includes the classes HttpRequest and
HttpResponse, which implement HTTP 1.1 with both client-side and server side
functionality. You might find that to be of some interest, in view of the
mess that is HTTPSocket.

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

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-benchmar
> ks.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. :)