What other development system could get away with this?

Last semester, I did a class project where I compared a couple of approximate matrix decomposition methods for their ability to restore removed photo annotations. Since I already had an experimental frame created for this purpose in Matlab, I decided to continue developing implementations of the additional methods I was interested in comparing in Matlab as well. One of the methods I wanted to compare was Mor Naaman's neighboring time context, which of course requires date comparisons (rank annotations by the number of photos associated with them among pictures taken with X seconds of a candidate photo). This should be a simple built-in function call and, although somewhat annoying to deal with due to complexities of the Gregorian calendar, has been done in many other languages/frameworks (Java, C#, etc.). Looking around the Matlab documentation, I find the following 'Limitations' section of the etime() function:

"As currently implemented, the etime function fails across month and year boundaries. Since etime is an M-file, you can modify the code to work across these boundaries if needed."

What the heck? Not only is it not implemented correctly, they laugh in your face and just tell you to do it yourself. Further investigation reveals a copy of the docs with a 1994 copyright date containing a similar cop out! They've been sitting on this fix for 13 years! Searching around the web, I failed to find someone who had bothered to do this and share the library. "Great," I say to myself and proceed to add the value of C#'s DateTime.GetFileTime()'s function (which returns a long with the number of 100 nanoseconds since 1601). Granted, I only have second resolution on my photos anyway. Having look through Matlab's data types previously,
I know it has int64's, so there should be no problem. That is until I actually try to run it and I get the following error:

"Function 'minus' is not defined for values of class 'int64'."

What??? Further reading of the docs reveal the following:

"Note The arithmetic operators do not support operations on the data types int64 or uint64. Except for the unary operators +A and A.', the arithmetic operators do not support operations on complex arrays of any integer data type."

Who the heck doesn't bother to implement long arithmetic? In version 7.2 of a product? That is sold for hundreds of dollars? And why do they even support loading data into int64's if you can't do anything with them once they are loaded? To be fair, I found some docs from version 6 that had just announced the support for int64 comparison operators. Wonderful.

Fortunately, for my implementation, I realized that I was only using 12 digits of precision for my data's time values... so I just had to stick my 'long' data into a double and that was good enough to get my experiment working (although making me feel dirty in the process). I do have to wonder what the engineers at MathWorks are actually doing, if they haven't bothered implementing such basic things.