Daycount signature LocalDate?

I was curious about the signatures on, why dont they use LocalDate, for example,

double getDayCountFraction(final ZonedDateTime firstDate, final ZonedDateTime secondDate);

I wonder why it is not

double getDayCountFraction(final LocalDate firstDate, final LocalDate secondDate);

Is there ever a case where ZonedDateTime is needed in the calculation of a daycount fraction? In each implementation i can see, LocalDate is all that is needed, and i cannot think of a daycount which would need anything else?

I did wonder if you had in mind some idea to calculate time to expiry of a option, where the timezone and time of day would be important, and yet one might want to specify BU/252 or ACT/360 as the basis for the vols.


You are quite correct; daycounts as used in fixed income calculations do not require information about the time of day. The decision to (continue to) use ZonedDateTime was taken to allow easier use from the InstrumentDefinition subclasses. Keeping time and zone information for these instruments might seem like a bit of overkill, but it allows us to ask non-daycount-related questions (for example, has a cashflow payment occurred, has this future actually expired).

In addition, at some point OptionDefinition will be pulled into this hierarchy, which will mean that we will need something like an ACT/365.25 class (if we were to want to make sure that Black-Scholes greeks matched those provided by some data providers, for example), where ACT in this case does take time into account.

The ultimate solution to this is to add the method that you proposed - it’s obviously a very simple change, and will match people’s expectations of what these classes should do. I shall put it into Jira.