The Timing of Time

hernan.wilkinson at mercapsoftware.com hernan.wilkinson at mercapsoftware.com
Tue Apr 18 22:52:47 UTC 2006


Mensaje citado por Alan Lovejoy <squeak-dev.sourcery at forum-mail.net>:

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

Well, a TimeLineFilter is a "set defined by rules". That means that it includes
all the objects its rules includes. We provided rules like DayRule (for a
certain day, i.e. Sunday), DateRule (for a specific date, i.e. 24/03/06) or an
Argentine rule that makes all third Mondays of August non working days.
Chalten does not currently support Lunar Calendars that is needed to know when
Easter is, but the idea is to add support to those calendars (the Hebrew too).
A rule used by the TimeLineFilter only needs to implement the message #includes:
aPointInTime, so it is easy to create those rules you ask.

> What about one-of-a-kind non-business days, such as the closure of the NYSE
> due to a Presidential Funeral? 

Yes, that is supported. That is very important in financial applications.
All rules also can be constrained by a date interval, for example in Argentina a
new holiday was created last March twentyfourth. Here is an example on how to
add this new holiday to a TimeLineFilter:

argentineNonWorkingDays addDayOfMonthRule: March twentyFourth from: (March
twentyFourth, 2006) to: TheEndOfTime

TheEndOfTime is an abstractions that allows you to handle not-ended time
intervals. There is a TheBeginingOfTime object too.

>A Chronos SemnticDatePolicy will handle rules
> like that (and could easily be extended for even more comples cases.)
> 

I guess is very similar to what we have. I have not have the chance to see
Chronos in detail, just a quick look...

> I like the syntax of the Domain-Specific Language you're developing.  

Thanks! we always try to have a good design in the models we create and we
beleive it is very important for the model's language to be very close to the
natural language. That makes the model easy to understand, use, etc.

>There
> might be some really good synergy achievable from implementing Chalten on
> top of Chronos.

I think that's a good idea... as I mention in a previous mail, Maxi Taborda will
improve Chalten because it is part of the work he has to do with his master's
thesis... I think we should find a way to create a GREAT time model joining
forces from Chronos, Chronology and Chalten, taken the best of them (and kick
other languages ass!!! sorry for the last word, I could not contain myself...)
What do you think? If we can doit without taking too much time from us, I think
we can came up with a good model.

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