Can Aspose handle invalid dates in the document properties better?

The attached file is a PDF created by SnagIt, a screen capture tool that can export to PDFs. It has invalid creation date and modified date properties - they are both set to an empty string, which is not an invalid date. This isn’t the only tool we’ve found that sets those dates using empty strings.



The problem we’re having is that Aspose.Pdf doesn’t handle those fields being empty strings very well. If you open the document using Aspose and try to access the Document.Info.CreatedDate or Document.Info.ModDate properties, an exception is thrown (Aspose.Pdf.Exceptions.InvalidValueFormatException) when it tries to parse the empty strings. This happens whether you’re setting or getting the property.



The obvious workaround is to work with the properties directly, which is what we’ve been doing, but is there any way to make it so those properties don’t throw exceptions just because someone stored an empty string where there should be a date string? The format a string needs to be in for a PDF date isn’t one of the standard types provided by the .NET date formatter, so you have to do it yourself, which works but is annoying to have to support. If in place of an empty string, or even a poorly formatted string, it could simply return a null value or Date.MinValue or something, it’d make handling these situations easier. For instance, it’d be nice to still be able to set the CreatedDate property to a valid date even if its current value isn’t valid, but instead you have to use the Item property and the text index “CreationDate” to access it, after formatting the date properly yourself.



This one is easily worked around, so it’s not that big of a deal, but if the handling of invalid date strings could be improved, it would make life a bit better for me and my clients.



Thanks,

Michael Whalen

Hi Michael,


Thanks for your inquiry. I have noticed the exception while updating empty Creation date, however ModDate is being updated without any issue. I have logged a ticket PDFNEWNET-39613 in our issue tracking system for further investigation and rectification. We will keep you updated about the issue resolution progress within this forum thread.

We are sorry for the inconvenience.

Best Regards

I’d also be interested in a fix for this issue as it is stopping us upgrading our version of Aspose.pdf

Hi Martin,


Thanks for your interest in our API’s.

The issue is still pending for review and is not yet resolved. However as soon as we have some definite updates regarding its resolution, we will let you know. We are sorry for this inconvenience.

We see a similar issue however we are not creating the PDFs but are using PDFs created by other sources.

Freedom Solutions:
We see a similar issue however we are not creating the PDFs but are using PDFs created by other sources.
Hi Kim,

The issue reported earlier is pending for review and is not yet resolved. However concerning to the issue with your input files, please share sample files so that we can test the scenario in our environment. We are sorry for your inconvenience.

Attaching sample file

Hi Kim,


Thanks for sharing the source document. We have tested the scenario and noticed that API is throwing different exception against your document, so we have logged another issue PDFNEWNET-40499 in our issue tracking system and grouped with the above reported issue, so both issues will be investigated together. We will keep you updated about the issue resolution progress.

We are sorry for the inconvenience caused.

Best Regards,

The issues you have found earlier (filed as PDFNET-40499) have been fixed in Aspose.PDF for .NET 25.6.