Version 1.9 - Option to ignore "Bad date/time format in the zip file"

Sep 1, 2009 at 3:49 AM

First, it is a brilliant library!

It is reasonable that the date and time is appropriate for each zipped file within one zip file, however, some (commercial) programs still create zip file that contains files with strange date and time (not limitted to the cases already better handled by the latest version).

Since this bad date and time exception will cause failure when read such zip files, it would be great if an option could be provided in version 1.9 that indicate whether to ignore such bad date and time, and default value for this option could be true, and user can turn if off if they want a strict check on date time for the zipped file.

It could be a public static bool property for ZipFile class, or other better idea/implementation.

Following is a rough implementation within PackedToDateTime function to illustrate the basic idea (better implementation would be more than welcome):

            ...

            catch (System.ArgumentOutOfRangeException)
            {
                if (IgnoreBadDateTime)
                {
                    return new System.DateTime(1980, 1, 1, 0, 0, 0, 0);
                }
                else
                {
                    if (year == 1980 && month == 0 && day == 0)
                    {
                        try
                        {
                            d = new System.DateTime(1980, 1, 1, hour, minute, second, 0);
                            success = true;
                        }
                        catch (System.ArgumentOutOfRangeException)
                        {
                            try
                            {
                                d = new System.DateTime(1980, 1, 1, 0, 0, 0, 0);
                                success = true;
                            }
                            catch (System.ArgumentOutOfRangeException) { }
                        }
                    }
                }
            }

            ...

 

Thanks a lot.

Best regards.

 

Coordinator
Sep 1, 2009 at 4:34 AM

Thank you for the suggestion.

I don't really understand how your proposed change would work.  What specific problem do you see it solving? 

Maybe you could provide for me a description of what happens now, and what would be better with the proposed change?

In looking at your code, I can see that the IgnoreBadDateTime property applies when the parsing of the embedded time within a zip file has failed. There is handling for those failed times already, as you can see.  In the error handling that exists today, I use an approach that relaxes constraints progressively as parsing the time fails.  I did this because people had brought me zip files that had valid times, but invalid dates.  

What would your flag do differently?

I'm trying to understand why it would be better.

Also you suggested that there are commercial programs that generate broken zip files.  Which programs?  Why not ask them to generate correct zip files?  And, what is different about the bad dates in those files that is not well handled in the current approach?

 

Sep 1, 2009 at 10:38 AM

Thanks a lot for your swift reply.

The bad date time example I encountered is: year = 1980, month = 1, day = 0, so it finally causes an exception even with current exception handling in latest 1.8.4.22, and the zip file is OK, not currupted (other zip tools can open them), but only bad on date time data (and is different to the cases already better handled by current code).

I guess possible other (commercial) tools may create other different bad/strange date time cases as well (though we do not know how it would be yet), since such zip files are OK except for only bad date time issue, an option would be better to handle all similar cases in the future, otherwise, has to adjust the exception handling code each time when encounter a new kind of such bad date time zip file.

For the comercial programs, I am not powerful enough to influence their development team, but have to handle such zip files :-(.

BTW, the extension for the example file is *.xlz (zipped xliff file), not zip.

Sorry that I could not provide the whole example zip file to you because it is from one of our real projects which contains customer data, following are the head bytes for the entry, hope it would be useful:

50 4B 03 04 14 00 00 00 08 00 00 00 20 00 EE AD F8 66 A9 BE 02 00 E2 C5 14 00 13 00 00 00 77 6F 72 6B 62 65 6E 63 68 5F 74 61 73 6B 73 2E 78 6C 66

 

Thanks again.

Coordinator
Sep 1, 2009 at 5:24 PM
Edited Sep 2, 2009 at 3:07 AM

OK I understand.

I am reluctant to add new interfaces to the library, new things to document and deal with. I'd rather the library just handle poorly formatted dates automatically. So I don't like the idea of another property on the zipfile class.  I propose making a change from this

catch (System.ArgumentOutOfRangeException)
{
    if (year == 1980 && month == 0 && day == 0)
    {
        try
        {

...to this:

catch (System.ArgumentOutOfRangeException)
{
    if (year == 1980 && (month == 0 || day == 0))
    {
        try
        {

This should handle your case, right?

 

Sep 2, 2009 at 2:20 AM

Understood. Thank you.

The proposed change will be welcome.

It would be a pity that there might be other new kind of bad date time in the future (seems some programs does not care about the date time in zip file - this include even Office 2007 format files, such as docx, xlsx, pptx, etc.).

Anyway, I can adjust and re-compile the library locally when necessary if it is not good to add new interfaces to the library globally.

Best Regards.