0
$\begingroup$

Hi I'm trying to advance a business date (28-12-2012) by 1 day and 1 week according to the Japan calendar.

import QuantLib as ql

trade_date = ql.Date(28, 12, 2012)
calendar = ql.Japan()

calendar.advance(trade_date, ql.Period('1D'))
Out[23]: Date(4,1,2013)

calendar.advance(trade_date, ql.Period('1W'))
Out[24]: Date(4,1,2013)

Seems a bit strange advancing the trade date by one day or one week give the same result. Any ideas why this might be the case? The 1 day result looks right. But the 1 week result seems off.

Incidentally

calendar.advance(ql_trade_date, ql.Period('5D'))
Out[25]: Date(10,1,2013)

How is calendar.advance(ql_trade_date, ql.Period('1W')) to be interpreted? I was trying to compute the expiry of a 1 week option.

$\endgroup$
5
  • $\begingroup$ A more fundamental problem is, what is "Japan calendar"? E.g. looking at financialcalendar.com/wp-content/uploads/coverage/… , I see 39 Japan calendars, including ISDA Standard TYO holidays, Tokyo bank holidays, and TONA (Tokyo Overnight Average) non-publication days. We really should stop using the poor architecture in QuantLib that assumes the existence of some kind of "country" or "currency" holiday. $\endgroup$ Commented Mar 1, 2021 at 21:09
  • 1
    $\begingroup$ QuantLib does have multiple calendars per country — see UnitedStates for instance. The Japan class can be extended in the same way given a motivated contributor. $\endgroup$ Commented Mar 2, 2021 at 8:39
  • $\begingroup$ @Luigi Ballabio Agreed, the calendar classes can easily expanded similar to the US calendars. $\endgroup$
    – AUK1939
    Commented Mar 2, 2021 at 10:36
  • $\begingroup$ Thanks. IMHO it would be better if UnitedStates() etc by itself did not work, but required the caller to be more specific. People get confused as to whether Good Friday, Columbus Day, etc are "U.S. holidays". $\endgroup$ Commented Mar 2, 2021 at 16:16
  • $\begingroup$ I see, so the constructor would force passing the specific market. Good point. $\endgroup$ Commented Mar 5, 2021 at 12:24

1 Answer 1

1
$\begingroup$

A decent calendar library should go beyond ql.Japan().isBusinessDay(d) and be able to explain why a day is not a business day.

December 28, 2012 is a Friday, a working day.

December 29, 2012 is a Saturday, not a working day.

December 30, 2012 is a Sunday, not a working day.

December 31, 2012 is a December 31 bank holiday https://www.timeanddate.com/holidays/japan/december-31-bank-holiday

January 1, 2013 is New year's day

January 2, 2013 is January 2 bank holiday https://www.timeanddate.com/holidays/japan/january-2-bank-holiday

January 3, 2013 is January 3 bank holiday https://www.timeanddate.com/holidays/japan/january-3-bank-holiday

January 4, 2013 is Friday, the next working day after December 28, 2012.

You may find these comments in the code helpful: https://rkapl123.github.io/QLAnnotatedSource/dc/d44/class_quant_lib_1_1_japan.html

$\endgroup$
7
  • $\begingroup$ Thanks @Dimitri Vulis. Have you got any other libraries you would recommend? I'm aware of the holiday list, but that doesn't answer the question why the 2 calls above give the same result. I would have expected the 1w call to advance by 5 business days. $\endgroup$
    – AUK1939
    Commented Mar 2, 2021 at 10:22
  • 2
    $\begingroup$ The 1w call advances by one week, so from Dec 28th to Jan 4th, and then possibly adjusts to the next business day (not in this case, as Jan 4th is a business day already). In short, weeks work like months or years. $\endgroup$ Commented Mar 2, 2021 at 10:44
  • $\begingroup$ Thanks that makes sense $\endgroup$
    – AUK1939
    Commented Mar 2, 2021 at 11:17
  • 1
    $\begingroup$ I once added a call to the firm's internal (sorry) library that took a calendar (like "NYK&London" because term sheets often use a union of 2 or 3 calendars), start date, and end date, and returns a structure listing the dates and clearly explaining why (e.g. New Years day (Observed) in NYK and London). $\endgroup$ Commented Mar 2, 2021 at 16:21
  • 1
    $\begingroup$ @DimitriVulis Agree this would be a useful feature in QuantLib $\endgroup$
    – AUK1939
    Commented Mar 3, 2021 at 15:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.