Hi,We are thinking about constructing a lot of date routines to be used as utility function, i.e., julian month, end of month market day, next market day, etc. Does anyone have experiences on this that can share with us? thanks

Tough work but worth it. If you deal with options, you should give some thought to creating a date/time object to allow you measure theta continuously and capture intra day (and especially maturity day) time premium correctly. It is amazing how some expensive trading apps return only intrinsic value on option maturity days!

A date class can grow to be a big thing. Describing one properly neads a whiteboard, more than a text based forum.This base type recognises that it is the Market, not the Country that determines holidays.TimeZone is a placeholder for the fact that "Days" are not always 24hrs. If you're crossing markets they may be more or less, and with FX can be very long indeed.class Market{ Name TimeZone }This is another base class, and if you're doing the job properly, all these members are abstract, requiring implementation to actually be used.class Date{ IsBusinessDay (is day a business day in this market ?) NextBusinessDay LastBusinessDay DaysUntilNextBusinessDay returns Interval; DaysSinceLastBusinessDays returns Interval;}The idea is to have a generic Date class, then for each market fill in the details.You don't want a Date class that knows about all markets. Actually you do, but you can't have one.If you go for a big class, it will force the maintainers to keep meddling with it, as new markets are added to the system. Very easy for them to break it.Example:Class FTSEDate : Derived from Date{Implements all Date functions }Thus Date is an interface class, and FTSEDate, NasDaqDate etc all comply with the same standard, but work out the values themselves.class Interval{ Elapsed_Days; Business_Days;}It is tempting to make the members of these classes, data, not functions. Bad move. Holidays are not static. All markets change their holidays, sometimes at quite short notice. Even when they don't you'd be amazed how often a source of data on holidays is simply wrong. Thus when you handle these things, it is vastly safer to pass around things that work out their values dynamically. But slower as well...If you're using them in any intensive way, it is worth cacheing the date info. Hash tables are one idea, but depends what you're doing.These classes live on top of some sort of calendar database that stores all days even when they don't have a holiday.Personally, I'd normalise it thus:DateTime Day;String DateName ( Monday, Christmas Day, etc.)Boolean IsHolidayThus you have one table entry for each day in each market. Some people will complain this waste space. It does. But you get a tougher system, and the space we're "wasting" is a fe tens of Mb, (ie less than on my watch)

I agree that a Date class can grow to be a big thing, which is why I prefer a different approach than DCFC's. I prefer small classes with one (or at most two) well defined responsibilities. My Date class is responsible for going to/from Year/Month/Day to an internal julian representation, and for doing simple (non-business day) date arithmetic. A separate Calendar class is responsible for determining whether or not a given Date is a good business day or not and for handling common business day related queries (like nextBusinessDay(), previousBusinessDay(), nthBusinessDay(), lastBusinessDay(Month), etc.). Then I have a separate MarketConventions class which determines which Calendar(s) to use when asked to calculate things like spotDate(tradeDate), fixingDate(valueDate), forwardDate(spotDate, nMonthsFwd), ... .Also, it is wise to keep separate the concepts of Date and Time. Carrying the Time inside of the Date causes a lot of baggage to be brought along when its not needed. It is a good idea to have a Timestamp class, consisting of Date/Time/Timezone, which uniquely identifies a point in time (i.e., can convert to/from universal time for comparisons). And it is handy to have a DateRange class for identifying interest accrual periods and which acts as the input to your DayCount class(es).Lastly, keep display aspects out of the Date class. Have a separate class (or class hierarchy) be responsible for going to/from all the different Date/Time formats (like YYYY-MM-DD, DD/MM/YY, MM/DD/YY, DD-MMM-YY, etc.). Then as your display requirements change you won't have to rebuild/retest all the code which relies on your Date class.

Adfin Calendars by Marvin is sold by Reuters.We found it expensive, so we made our own.Let me know if we can sells ours to you.But, there again, you might want to make YOUR own.

I think that EJV also has a market day calendar.Also, I was able to find some open source code converting from Julian date and Gregorian calendat date. I think that it will be better to also have a Julian month conversion routine in place. But I was unable to find any. Does anyone know about formula to convert between Julian month and Gregorian month?thanks,

Jim's approach is also sensible. Can't honestly tell you which is better. It all depends upon what you're going to do with it.One can go into a lot of formal analysis of these things. BUt a good compromise is to just do some walk throughs on the uses you exepct to make of it.

Fliegel and van Flandern (1968) published compact computer algorithms for converting between Julian dates and Gregorian calendar dates. Their algorithms were presented in the Fortran programming language, and take advantage of the truncation feature of integer arithmetic. The following Fortran code modules are based on these algorithms. In this code, YEAR is the full representation of the year, such as 1970, 2000, etc. (not a two-digit abbreviation); MONTH is the month, a number from 1 to 12; DAY is the day of the month, a number in the range 1-31; and JD is the Julian date at Greenwich noon on the specified YEAR, MONTH, and DAY. Conversion from a Gregorian calendar date to a Julian date.Valid for any Gregorian calendar date producing a Julian date greater than zero: INTEGER FUNCTION JD (YEAR,MONTH,DAY)CC---COMPUTES THE JULIAN DATE (JD) GIVEN A GREGORIAN CALENDARC DATE (YEAR,MONTH,DAY).C INTEGER YEAR,MONTH,DAY,I,J,KC I= YEAR J= MONTH K= DAYC JD= K-32075+1461*(I+4800+(J-14)/12)/4+367*(J-2-(J-14)/12*12) 2 /12-3*((I+4900+(J-14)/12)/100)/4C RETURN END Conversion from a Julian date to a Gregorian calendar date: SUBROUTINE GDATE (JD, YEAR,MONTH,DAY)CC---COMPUTES THE GREGORIAN CALENDAR DATE (YEAR,MONTH,DAY)C GIVEN THE JULIAN DATE (JD).C INTEGER JD,YEAR,MONTH,DAY,I,J,KC L= JD+68569 N= 4*L/146097 L= L-(146097*N+3)/4 I= 4000*(L+1)/1461001 L= L-1461*I/4+31 J= 80*L/2447 K= L-2447*J/80 L= J/11 J= J+2-12*L I= 100*(N-49)+I+LC YEAR= I MONTH= J DAY= KC RETURN END Example: YEAR = 1970, MONTH = 1, DAY = 1, JD = 2440588.

The formula given below was taken from the U.S. Naval Observatory's no-longer- published Almanac for Computers for 1990.The Julian date (JD) is a continuous count of days from 1 January 4713 BC (= -4712 January 1), Greenwich mean noon (= 12h UT).For example, AD 1978 January 1, 0h UT is JD 2443509.5 and AD 1978 July 21, 15h UT, is JD 2443711.125. Conversion of Gregorian calendar date to Julian date for years AD 1801-2099 can be carried out with the following formula: JD = 367K - <(7(K+<(M+9)/12>))/4> + <(275M)/9> + I + 1721013.5 + UT/24 - 0.5sign(100K+M-190002.5) + 0.5 where K is the year (1801 <= K <= 2099), M is the month (1 <= M <= 12), I is the day of the month (1 <= I <= 31), and UT is the universal time in hours ("<=" means "less than or equal to"). The last two terms in the formula add up to zero for all dates after 1900 February 28, so these two terms can be omitted for subsequent dates. This formula makes use of the sign and truncation functions described below: The sign function serves to extract the algebraic sign from a number.Examples: sign(247) = 1; sign(-6.28) = -1. The truncation function < > extracts the integral part of a number.Examples: <17.835> = 17; <-3.14> = -3. Example: Compute the JD corresponding to 1877 August 11, 7h30m UT.Substituting K = 1877, M = 8, I = 11 and UT = 7.5,JD = 688859 - 3286 + 244 + 11 + 1721013.5 + 0.3125 + 0.5 + 0.5= 2406842.8125

This may be the American standard.Alas, the Russians did their calculation later, and to greater accuracy, so it is not a world standard.