I haven't looked into the technical credibility of this at all [EDIT: I should have more strongly indicated my doubt here], so this isn't any sort of condemnation on my end, but I thought the Leap Day theory was interesting:
Seems like infra problems.
As for believing/unbelieving, I mean, I've seen dumber mistakes in financial products I've worked on. Not as high stakes or damaging, but definitely dumber.
That at least means that some portion of their stack used roll your own datetime library. That would not actually be a problem as long as the entire stack got the same library or the same rules for datetime. The problem is of course that it probably did not so the libraries were not bug compatible which of course caused errors and those errors need to be handled, preferably every fast.
Error load and error handling is the least tested part of every system because it can only be properly tested in production and, unless your company embraces the Chaos Monkey approach to testing, the C-level would have a heart attack when anyone proposes doing it.
https://api.robinhood.com/markets/XASE/hours/2020-03-03/
vs
https://api.robinhood.com/markets/XASE/hours/2020-03-07/
This whole discussion lacks context to the nature of the requests, aka a front end code review.
Somewhere within the infrastructure there's going to be an assertion such as
if (max_drift_delta > delta(order_live_date,system_live_date) {
# oh crap, something is completely broken in our system where did this come from?
blow_up("terrible things are happening! how did we get this order")
}
And since RH has lots of people who use apps, it is not that they can just push an immediate bugfix.
I spent a better part of a year working on it (along with other things). Modeled the interface after Python's datetime module (which I think is one of the simpler and easy to use date-time libraries across various languages I've used). More than $20B USD trades using that library.
The motivation was the firm used to use RogueWave's date-time facilities, but we moved away after they jacked up the licensing. Think we used to have a site-wide license, but they were moving to a per-core licensing, wanting something like $2K per core annually.
Needless to say, testing was extensive. Overflows were found in Boost in far distant dates, had to work around those. Tested against a ton of historical dates. Tested against Northern and Southern Hemisphere daylight saving time (a lot of people don't realize that Southern is inverted from Northern). Learned a lot about timezones and the history of timezones along the way.
[0] https://www.boost.org/doc/libs/1_72_0/doc/html/date_time.htm...