4 ms·

Kenneth Reitz is a testament to how important good interfaces are in the developer community. There are literally 0 interesting things in the code (all dependen

Kenneth Reitz is a testament to how important good interfaces are in the developer community. There are literally 0 interesting things in the code (all dependency driven, https://git.io/v15i3 https://git.io/v15i3). It does have a nice interface and because of this it will probably become one of the more popular python datetime libs.

vegabook 10y ago
Arguably bringing multiple dependencies under one roof, with a nice, human-readable interface, is exactly what the value is here. This SO answer from Pandas lead Wes Mckinney says it better than anything I could comment. Python datetime/timestamp management: "Welcome to Hell" http://stackoverflow.com/questions/13703720/converting-between-datetime-timestamp-and-datetime64 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.
- dom0 10y ago
  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.
  - vegabook 10y ago
    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....
  - smallnamespace 10y ago
    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 https://en.wikipedia.org/wiki/Day_count_convention [2] https://en.wikipedia.org/wiki/Date_rolling https://en.wikipedia.org/wiki/Date_rolling Funny thing is these have all probably be reimplemented from scratch at every single bank.
    - vegabook 10y ago
      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.

vegabook 10y ago

Arguably bringing multiple dependencies under one roof, with a nice, human-readable interface, is exactly what the value is here. This SO answer from Pandas lead Wes Mckinney says it better than anything I could comment. Python datetime/timestamp management: "Welcome to Hell" http://stackoverflow.com/questions/13703720/converting-between-datetime-timestamp-and-datetime64 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.

dom0 10y ago
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.
- vegabook 10y ago
  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....
- smallnamespace 10y ago
  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 https://en.wikipedia.org/wiki/Day_count_convention [2] https://en.wikipedia.org/wiki/Date_rolling https://en.wikipedia.org/wiki/Date_rolling Funny thing is these have all probably be reimplemented from scratch at every single bank.
  - vegabook 10y ago
    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.