Skip to content
All library documents

QuantLib Dates Store No Time or Time Zone by Default

Article Quant Q&A · Author: darkuss
Read the original

Summary

QuantLib’s Date type represents a calendar date without a time of day in its standard configuration. A date passed to the library therefore does not imply midnight, machine-local time, or any other clock time; it carries no time information at all.

A build option can add time fields, but it is disabled by default because it adds overhead and requires rebuilding both QuantLib and its Python wrappers. Even with that option, Date can represent a clock time such as 4 p.m. but cannot attach a time zone such as New York. Applications that need timezone-aware timestamps must handle timezone conversion themselves and keep their time conventions consistent. The answer explains the library’s capabilities and configuration tradeoffs, but does not provide a trading strategy or performance measurements.

Key ideas

  • A default QuantLib Date records a calendar date and has no time-of-day component.
  • Time support requires a non-default build and recompilation of QuantLib and its Python wrappers.
  • The optional time fields do not include timezone information.
  • Applications must convert times to a consistent convention outside QuantLib Date.

Tags

Statistics
Full text
# Quantlib date hour time in ql.Date()


# Quantlib date hour time in ql.Date()












How does the quantlib set up hour time, say in the example below:

ql.Date(20, 1, 2023), US calendar,

what is the time, 12 AM US time? local machine time?

say I would like to set up a NY 4 pm time, is it possible?

## Answer by Luigi Ballabio (score 4, accepted)

https://quant.stackexchange.com/a/74423

By default, an instance of Date is just a date and doesn't have time information.

It's possible to compile QuantLib so that it also has a time (see here), but this is not enabled by default since it slows down the library. If you do choose that configuration, you'll need to recompile both QuantLib and its Python wrappers yourself.

Also, the non-default configuration allows Date instances to have a time, but not a timezone. You'll be able to say `ql.Date(20, 1, 2023, 16, 0, 0)` to specify 4PM, but not that it's NY time. It leaves it up to you to convert and use consistent times.

Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.