http://stackoverflow.com/questions/13703720/converting-betwe...
I run batch and real time financial feeds into Python from multiple sources, inevitably from different programming language paradigms, and with different time/date/timezone conventions, and then I allow user interaction with it in their own lingo for dates and times, and my experience is that it is indeed hell consolidating all this into a common tongue. The "slang time" idea suggest to me that this library understands the need for flexibility and malleability in this very disjointed and often frustrating part of the Python ecosystem.
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.
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.
https://github.com/lballabio/QuantLib/tree/master/ql/time/da...