The Timing of Time

Alan Lovejoy squeak-dev.sourcery at forum-mail.net
Mon Apr 17 16:36:00 UTC 2006


Hernan:

Can a TimeLineFilter handle rules such as "the day after the fourth Thursday
of November," "two days before Easter" or "Nisan 14 (Hebrew Calendar)"?
What about one-of-a-kind non-business days, such as the closure of the NYSE
due to a Presidential Funeral? A Chronos SemnticDatePolicy will handle rules
like that (and could easily be extended for even more comples cases.)

I like the syntax of the Domain-Specific Language you're developing.  There
might be some really good synergy achievable from implementing Chalten on
top of Chronos.

--Alan

-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of Hernan
Wilkinson
Sent: Monday, April 17, 2006 7:30 AM
To: The general-purpose Squeak developers list
Subject: Re: The Timing of Time

Hi Alan, Francisco,
    we also created a model to deal with dates and time issues because of
the same issues you and Brent mentioned. We uploaded last week to squeak
source, it is named Chalten.
Alan Lovejoy wrote:

>Garau wrote:
>
>"- 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)
>
>
With Chalten, the code would be:
(April, 2006 to: March, 2007) collect: [ :aMonthOfYear | aMonthOfYear
lastDate ]

or:

((GregorianMonth april yearNumber: 2006) to: (GregorianMonth march
yearNumber: 2007)) collect: [ :aMonthOfYear | aMonthOfYear lastDate ]

>"- 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.
>
>
Because we created Chalten to deal with financial software, this kind of
problem are easy to solved.
There is an abstraction called "TimeLineFilter" that allows you to filter
the time line of any granularity and walk over the filtered time points.
So, to get due working days, the code would be:

(April, 2006 to: March, 2007) collect: [ :aMonthOfYear | MonthBasedDueDate
for: aMonthOfYear lastDate in: britishWorkingDays ]

With this code you will get all the due date in as working days of the
british working calendar.
The britishWorkingDays object is a TimeLineFilter, that can be created this
way:

britishNonWorkingDays := TimeLineFilter new.
britisNonWorkingDays
    addDayRule: GregorianDay saturday;
    addDayRule: GregorianDay sunday;
    addDayOfMonthRule: December twentyFifth.
britishWorkingDays := britishNonWorkingDays negated.

As you can see, you first create a filter that includes the non working days
(because they are less that the working days) and the you the the "negated"
filter, that is the working days.

About the day count conventions like 30/360, 30/365, Actual/Actual, etc.
that are used to calculate the "real" interest rate to pay for an
investment, we also have objects to deal with that but they are not part of
Chalten because that is a pure financial problem. But to deal with them we
use an abstraction that we have in Aconcagua (the measure's model that we
opened too) called "Evaluation". An Evaluation is an object that has a
meaning by itself but it is used in arithmetic operations. A good example of
Evaluation is a class we called Interest.
For example:

(Interest simpleFor: 1000 * dollar with: (InterestRate yearlyOf: 1/10)
during: 2 * TimeUnits year) value --> This will return 200 dollars.
(dollar is a unit, 1000 * dollar creates the measure 1000 dollars. 2 *
TimeUnits year create the measure 2 years).

Another example of Evaluation in the financial domain InterestRate,
NetPayment, GrossPayment, etc. (In physics Speed, Aceleration, etc. are good
examples).

Hernan.

>"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: squeak-dev-bounces at lists.squeakfoundation.org
>[mailto:squeak-dev-bounces at lists.squeakfoundation.org] 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/10014
>8
>
>
>
>
>
>
>
>


--
______________________________
Lic. Hernán A. Wilkinson
Gerente de Desarrollo y Tecnología
Mercap S.R.L.
Tacuari 202 - 7mo Piso - Tel: 54-11-4878-1118 Buenos Aires - Argentina
http://www.mercapsoftware.com
---------------------------------------------------------------------
Este mensaje es confidencial. Puede contener informacion amparada por el
secreto profesional. Si usted ha recibido este e-mail por error, por favor
comuniquenoslo inmediatamente via e-mail y tenga la amabilidad de eliminarlo
de su sistema; no debera copiar el mensaje ni divulgar su contenido a
ninguna persona. Muchas gracias.

This message is confidential. It may also contain information that is
privileged or otherwise legally exempt from disclosure. If you have received
it by mistake please let us know by e-mail immediately and delete it from
your system; you should also not copy the message nor disclose its contents
to anyone. Thanks.
 ---------------------------------------------------------------------






More information about the Squeak-dev mailing list