The Timing of Time

Hi!

"Alan Lovejoy" <[hidden email]> 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. :)

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

On Apr 13, 2006, at 12:08 AM, [hidden email] wrote:
>
> 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. :)

What I can contribute here is that the performance benefits are more  
than just theoretical - the poor performance of the Chronology  
package has been responsible for a significant percentage of the  
bottlenecks in our production code recently.  More than once, our  
profiling has led us to some part of Chronology that was an order of  
magnitude or two slower than it needed to be.  The most recent  
example of a couple of days ago was DateAndTime>>hash - try sticking  
a few thousand dates into a Set and you'll see what I mean.  That can  
be sped up, in some cases, by a simple optimization in  
DateAndTime>>asUTC:

asUTC
        ^ offset isZero
                ifTrue: [self]
                ifFalse: [self utcOffset: 0]

Avi

On Thursday 13 April 2006 09:37, Avi Bryant wrote:
Hi Avi,

Do not forget to use this improvment that Dan Ingalls submitted:

DateAndTime>>dayOfYear
        "This code was contributed by Dan Ingalls. It is equivalent to the terser
                ^ jdn - (Year year: self year) start julianDayNumber + 1 but much quicker."

        | monthStart |
        ^ self dayMonthYearDo:
                [ :d :m :y |
                        monthStart := #(1 32 60 91 121 152 182 213 244 274 305 335) at: m.
                        (m > 2 and: [ Year isLeapYear: y ])
                                ifTrue: [ monthStart + d ]
                                ifFalse: [ monthStart + d - 1 ]]
!

This is, I believe already in the 3.9 image.

Brent

"Brent Pinkney" <[hidden email]> wrote:

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

Thank goodness we live in a nice simple timezone! Yay SAST! But yes, I guess
it means we don't enjoy the full pain and suffering wrought upon programmers
by things like British Summer Time.

frank

Avi Bryant wrote:
> What I can contribute here is that the performance benefits are more
> than just theoretical - the poor performance of the Chronology package
> has been responsible for a significant percentage of the bottlenecks in
> our production code recently.

Heh. "me too". In my case it was printing. Would be interesting to see
how long a #printString takes for either one.

Cheers,
   - Andreas

Am 13.04.2006 um 11:15 schrieb Andreas Raab:

> Avi Bryant wrote:
>> What I can contribute here is that the performance benefits are  
>> more than just theoretical - the poor performance of the  
>> Chronology package has been responsible for a significant  
>> percentage of the bottlenecks in our production code recently.
>
> Heh. "me too". In my case it was printing. Would be interesting to  
> see how long a #printString takes for either one.

For me, it was the space inefficiency. I ran into this when trying to  
put many monticello version infos into a database. MC stores a Date  
and a Time separately, for historic reasons. Dates used to be just a  
simple offset in days. Nowadays, they have a start, a timezone  
offset, and a duration, each of which is a full object, and all are  
in nanosecond precision. So we have 4 times as many objects, taking  
like 10 times the space necessary.

- Bert -

On Thu, Apr 13, 2006 at 11:47:56AM +0200, Bert Freudenberg wrote:
I learned a couple of things in the course of implementing time zones
(TimeZoneDatabase on Squeak Map) that can have a big impact on performance.

In order to implement time zones correctly, I created class PointInTime.
This represents time independently of calendars and time zones, and
(on Squeak) uses ScaledDecimal for its numeric representation. It is
also tied in to Squeak's DateAndTime and TimeZone to allow conversions
back and forth, and to allow DateAndTime and Duration to use the time
zones in the time zone database.

Here's what I learned:

1) ScaledDecimal is a very nice way to represent time magnitudes. It has
unlimited precision, and is computationally efficient because time values
tend to be simple integer values derived either from user input or from
the hardware clock on your computer.

2) Both DateAndTime and TimeZone can be thought of as the external
representation of a PointInTime. They are meaningful to people, but it
is difficult to get them to behave like magnitudes (certainly this is the
case if you want them to be both and correct *and* fast). If you want to
do a lot of time and duration calculations (for example in Montecello),
it is preferable to do the calculations with e.g. PointInTime, and to
present the results (human readable time stamps) as DateAndTime.

Dave



 

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: [hidden email]
[mailto:[hidden email]] On Behalf Of
[hidden email]
Sent: Thursday, April 13, 2006 12:08 AM
To: The general-purpose Squeak developers list
Subject: Re: The Timing of Time

Hi!

"Alan Lovejoy" <[hidden email]> 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. :)

On Thu, 13 Apr 2006 18:37:10 -0700, Alan Lovejoy  
<[hidden email]> wrote:


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

A megabyte!? Whoa!

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Blake
Sent: Thursday, April 13, 2006 6:48 PM
To: The general-purpose Squeak developers list
Subject: Re: The Timing of Time

On Thu, 13 Apr 2006 18:37:10 -0700, Alan Lovejoy
<[hidden email]> wrote:


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

A megabyte!? Whoa!

Faster, better, cheaper: choose any two :-)

The current size of the virgin Squeak image would have shocked me silly back
in the late '80s.

--Alan

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: [hidden email]
[mailto:[hidden email]] 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" <[hidden email]> 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.

On Thu, 13 Apr 2006 18:53:13 -0700, Alan Lovejoy  
<[hidden email]> wrote:

> A megabyte!? Whoa!
>
> Faster, better, cheaper: choose any two :-)

Since I'm not paying, how about faster, better and smaller?<s>

> The current size of the virgin Squeak image would have shocked me silly  
> back
> in the late '80s.

Seems to me the Squeak is probably lightweight compared to VAST. But  
perhaps the acronym was self-fulfillng.

I'm intrigued by the articles I've read that suggest Squeak could be  
reduced to 1/10th its core size. I'd pay $50 to see that.

Hi Alan,

As yourself, I am also interested in date and times. I tried loading the
Chronos package following the instructions from your website [1], but
something went awry.

I succesfully loaded:
    1- Passport-Kernel
    2- Passport-Squeak
    3- Chronos-System-Squeak
    4- Chronos-System-Squeak-PostV3.6

The problem happens on step 3. The last two lines of that fileOut says:

    ChronosSqueakEnvironment initialize !
    ChronosEnvironment canonical install !

I guess that ChronosEnvironment should be a class and canonical a message.
But neither of them are in the image.

My interest on dates is more biased towards dates than towards times. Dates,
months, years and calendars are central objects in financial systems.
Amongst the many problems that arises in such systems, here a couple of
examples:

- Starting on the 31Mar2006 generate a schedule of payments every month
until 31Mar2007.
That should return 30Apr06 31May06 30Jun06 ... 28Feb07 31Mar07

- Adjust the previous schedule to the british and japanese calendar, making
sure all dates are 'good business days'. So, for example, if 30Apr06 falls
on Sunday or a british bank holiday, change it according to some rule.
Examples of such rules are:
next business day, next calendar day, etc.

It gets more complicated when you think about DCC (day count conventions).
In the first example we were dealing with actual months. But under the
30/360 DCC, every month has 30 days.

Dates can be seen from many different points of view. In a financial system
we are certainly not interested in the duration of a date. Not in
nanoseconds, not in milliseconds or even hours. A date is a business date.

I agree with the Mercap guys that dates, months and years are views of the
same time-line at different levels of granularity. In financial systems we
don't need to go further down that date. For other type of systems requiring
global syncronization, you probably need to go down to the millisecond
level. Furthermore, you need every time to be expressed as an offset from a
central location (Greenwich?).

That is my poor understanding of time-zones and the reason why I want to
play with the Chronos package.

Cheers,
Francisco

[1] http://chronos-st.org/frames/Squeak-Downloads.html
[2] http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/100148

On Fri, Apr 14, 2006 at 11:31:12AM +0100, Francisco Garau wrote:
>
> That is my poor understanding of time-zones and the reason why I want to
> play with the Chronos package.

Francisco,

If you want to explore time zones and their interaction with Chronology
in Squeak, you may want to also look at TimeZoneDatabase (Squeak Map).
This will not provide the range of functionality addressed by Chronos,
and it certainly will not help figure out calendar dates and business
calendars.  But you can use it to explore time zone maps and understand
how time zones affect time and duration in Squeak.

BTW, Alan's web site for Chronos provides some excellent documentation
and references to web sites that explain how time zones and time
measurement systems work. It sounds like it aught to be boring,
but it's actually quite interesting if you have a taste for arcane
technology and socio-political trivia.

Dave

Garau wrote:
"I succesfully loaded:
    1- Passport-Kernel
    2- Passport-Squeak
    3- Chronos-System-Squeak
    4- Chronos-System-Squeak-PostV3.6"

There's a file missing from your list: Chronos.st.  That needs to be filed
in third. Chronos.st defines ChronosEnvironment, among many other things.

"- Starting on the 31Mar2006 generate a schedule of payments every month
until 31Mar2007.
That should return 30Apr06 31May06 30Jun06 ... 28Feb07 31Mar07"

| schedule |
schedule := OrderedCollection new.
(Timeperiod from: (YearMonthDay year: 2006 month: 4 day: 1) duration:
(CalendarDuration years: 1 months: 0 days: 0))
        monthsDo: [:month | schedule add: month last].
schedule => OrderedCollection (2006-04-30 2006-05-31 2006-06-30 2006-07-31
2006-08-31 2006-09-30 2006-10-31 2006-11-30 2006-12-31 2007-01-31 2007-02-28
2007-03-31)

"- Adjust the previous schedule to the british and japanese calendar, making
sure all dates are 'good business days'. So, for example, if 30Apr06 falls
on Sunday or a british bank holiday, change it according to some rule.
Examples of such rules are:
next business day, next calendar day, etc.

It gets more complicated when you think about DCC (day count conventions).
In the first example we were dealing with actual months. But under the
30/360 DCC, every month has 30 days."

Chronos doesn't currently support the Japanese Imperial Calendar. I haven't
actually looked at that one, so I don't know how easy or hard it may be to
implement.  However, once implemented, adding new calendars to Chronos is
quite easy.

SemanticDatePolicy instances can be used to define holiday schedules using
any combination of supported calendars.  Extensible observance rules are
supported.  US Holidays (including all rule-based and
one-time-only-historical NYSE holidays) are predefined; others must be added
by the programmer.

So, modifying the first example to handle US banking holidays would look
like this:

| sdp holidays schedule dateSelector |
sdp := SemanticDatePolicy unitedStates.
holidays := SemanticDatePolicy usFederalHolidaySemanticKeys.
schedule := OrderedCollection new.
dateSelector :=
        [:date |
        date dayOfWeekKey == #Sunday
                ifTrue: [dateSelector value: (date addingDays: 1)]
                ifFalse:
                        [(date annualDateSemanticKeyFrom: sdp satisfies:
[:semanticKey | holidays includes: semanticKey])
                                ifTrue: [dateSelector value: (date
addingDays: 1)]
                                ifFalse: [date]]].
(Timeperiod from: (YearMonthDay year: 2006 month: 4 day: 1) duration:
(CalendarDuration years: 1 months: 0 days: 0))
        monthsDo: [:month | schedule add: (dateSelector value: month last)].
schedule => OrderedCollection (2006-05-01 2006-05-31 2006-06-30 2006-07-31
2006-08-31 2006-09-30 2006-10-31 2006-11-30 2007-01-02 2007-01-31 2007-02-28
2007-03-31)

The 30/360 DCC is trivial to implement, using CalendarDurations and
Timeperiods.

"Dates can be seen from many different points of view. In a financial system
we are certainly not interested in the duration of a date. Not in
nanoseconds, not in milliseconds or even hours. A date is a business date."

The class Chronos YearMonthDay is implemented just that way, for just that
reason.

Thanks for your questions. I'll be adding the second example to the website.

--Alan

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of
Francisco Garau
Sent: Friday, April 14, 2006 3:31 AM
To: The general-purpose Squeak developers list; Alan Lovejoy
Subject: Re: The Timing of Time

Hi Alan,

As yourself, I am also interested in date and times. I tried loading the
Chronos package following the instructions from your website [1], but
something went awry.

I succesfully loaded:
    1- Passport-Kernel
    2- Passport-Squeak
    3- Chronos-System-Squeak
    4- Chronos-System-Squeak-PostV3.6

The problem happens on step 3. The last two lines of that fileOut says:

    ChronosSqueakEnvironment initialize !
    ChronosEnvironment canonical install !

I guess that ChronosEnvironment should be a class and canonical a message.
But neither of them are in the image.

My interest on dates is more biased towards dates than towards times. Dates,
months, years and calendars are central objects in financial systems.
Amongst the many problems that arises in such systems, here a couple of
examples:

- Starting on the 31Mar2006 generate a schedule of payments every month
until 31Mar2007.
That should return 30Apr06 31May06 30Jun06 ... 28Feb07 31Mar07

- Adjust the previous schedule to the british and japanese calendar, making
sure all dates are 'good business days'. So, for example, if 30Apr06 falls
on Sunday or a british bank holiday, change it according to some rule.
Examples of such rules are:
next business day, next calendar day, etc.

It gets more complicated when you think about DCC (day count conventions).
In the first example we were dealing with actual months. But under the
30/360 DCC, every month has 30 days.

Dates can be seen from many different points of view. In a financial system
we are certainly not interested in the duration of a date. Not in
nanoseconds, not in milliseconds or even hours. A date is a business date.

I agree with the Mercap guys that dates, months and years are views of the
same time-line at different levels of granularity. In financial systems we
don't need to go further down that date. For other type of systems requiring
global syncronization, you probably need to go down to the millisecond
level. Furthermore, you need every time to be expressed as an offset from a
central location (Greenwich?).

That is my poor understanding of time-zones and the reason why I want to
play with the Chronos package.

Cheers,
Francisco

[1] http://chronos-st.org/frames/Squeak-Downloads.html
[2] http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/100148

HI alan

this sounds really interesting.
Does it mean that you have an abstraction over the ugly FileDirectory  
and friends.

So we could have this kind of behavior
        File default recursivelyDo: [:each | where each would be a  
resourcepath] ?

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

HI brent

what is your take on this?

On 14 avr. 06, at 03:37, Alan Lovejoy wrote:

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