Hacker News new | past | comments | ask | show | jobs | submit login

I think there are two separate issues here.

One thing is that some libraries bring their own not-really-different-just-different-enough-to-break-things date/time types to the table. That can be worked out over time, not that big of a problem, just inconvenient.

The other is that I've grown to think that the abstraction commonly used, seeing date/time as something like (year, month, day, hour, minute, second, subsecond, timezone) is in itself not really suitable, because the derived interfaces (like accessing and modifying days, months etc. separately) mean that most code working with these will inevitably be bug-ridden.

The root cause for this is imho that date and time are extremely complicated and it's usually unclear what the correct behaviour would be in any of the many, many edge cases.

Some examples:

1.) One week after `this` date. Does this mean, add seven days? What about leap days? Should the result be the same weekday, just in the next week instead?

2.) Start and end time of a process should be recorded. The process starts and finished. All good. The duration of the process is -1 hour and 5 minutes. Should instead a start timestamp be recorded and a monotonic duration? Or perhaps we should rather note the begin of a monotonic period and record an end timestamp, deriving the start timestamp? Which is correct?

3.) One ^W two words: recurrence rules

4.) DST

5.) Combining 3.) and 4.)!

dom's rule of thumb: if code does addition or substraction with some measure of time, it's probably wrong.




Regarding recurrence rules specifically, I worked in the financial services industry and bonds and derivatives obviously recur (usually monthly) for decades.

Not only do you need to specify the precise dates of recurrences, but you also need to map time intervals to fractions of a year (e.g. if I owe you $1mm a year, is 'one month' equal to 1/12 of a year, or do I count the actual numer of days in between? What about leap days, etc.). Getting it wrong even slightly means you get all the cashflows wrong.

Welcome to the joy of 'day count conventions' [1] and 'date rolling' [2].

[1] https://en.wikipedia.org/wiki/Day_count_convention [2] https://en.wikipedia.org/wiki/Date_rolling

Funny thing is these have all probably be reimplemented from scratch at every single bank.


I've personally re-implemented bond daycount for multiple markets several times at different shops. Maybe quantlib has this? Have never been allowed to use it.


Quantlib has a relatively small set implemented:

https://github.com/lballabio/QuantLib/tree/master/ql/time/da...


agreed and well put. Don't even get me started on R's inconsistencies between for example, base, and zoo/xts POSIXlt, POSIXct and as.date, when it comes to summer time changes. One lib counts 6 days the other counts 7! Because they've got different bugs. It's a mess precisely because each library has its own bugs for many of the edge cases you mention. Personally, because leap seconds are not important to me, I've gone with Unix epoch as the base "universal language" to/from which I convert everything. Conveniently it talks JS easily too. And I do everything UTC. Still, for example, it's a complete and utter nightmare when, for example, needing to bring the 30 different equity market indices I cover's opening and closing times around the world, into a single and consistent time framework, what with each country's weird different rules and daylight savings times, which, to make it even worse, have changed multiple (badly documented) times over the years, making historic analysis an exercise in True Pain. Finally, to meet Satan himself, try getting into fixed income market daycount conventions....




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: