Thank you for your insights, they are very useful.
I agree with you that when from/until are not specified, OAICat shouldn't make the assumptions it makes. It should leave such assumption for the application layer (e.g. in our case DSpace).
"Harvesting is restricted to the range specified by the from and until arguments, extending back to the earliest datestamp if from is omitted, and forward to the most recent datestamp if until is omitted."
I will file a bug with them and send them a patch removing these assumptions, but I'm afraid they won't be very responsive. I'll also try to contact particular authors.
Anyway, we have an alternative to waiting for them to fix it - our OAICat is pulled from Maven, so we could put the patched version of OAICat in our Maven repository. However, I don't think this would be a better solution than applying the workaround in DSpace, because it could mislead someone else who would try to use org.dspace.oaicat to think it's an unpatched version.
I understand the OAICat problem, but I still don't completely understand the Oracle problem. Why doesn't it accept these timestamps? What does timezone have to do with it? OAI-PMH mandates that all timezones used in the protocol must be in UTC. But why not convert them for use in the application to the local timezone?
Would it help to detect local timezone and use it this way?
This is the easiest thing to change, so if you have anything to put in the manual, please attach it here.