#81 Incorrectly parse dates

[Masar]

Hi,
I'm using davfs2 with SharePoint 2007 and it incorrectly parses the file and directory timestamps resulting in a 1970-1-1 (aka -1) date.

I did a simple patch that corrects the problem: basically you should use ne_iso8601_parse instead of ne_httpdate_parse where the files timestamps are returned.

Best Regars

[Masar]

patch of webdav.c

[Werner Baumann]

Logged In: YES
user_id=1260327
Originator: NO

Thanks for the report and the patch.

I had another look at RFC 4918. It indeed defines different time formats for creationdate and getlastmodified. It defines
- iso8601 for creationdate; there is a bug in davfs2
- rfc1123-date for getlastmodified, so davfs2 would be right here.

Besides what's right according to the spec, it is important to see, whether servers do it according to the spec. If there are no server-bugs, it would suffice, to fix the davfs2-bug in parsing creationdate. Otherwise, a second parsing in case of a failure, like your patch does, would be necessary.

I will check the servers, that I can access (mostly Apache and IIS 6.0) for this. Can you send me examples, how SharePoint sends the datestamps in the XML-body (and possibly other server brands, you deal with)?

Cheers
Werner

[Masar]

Logged In: YES
user_id=1972533
Originator: YES

Here is a trace of a request from davfs2 to a SharePoint server 2007
File Added: propfind.txt

[Masar]

The trace

[Werner Baumann]

Logged In: YES
user_id=1260327
Originator: NO

Thanks for the response from SharePoint server.

SharePoint seems to make the same mistake as davfs2, only the other way round. It uses ISO-date-format for creationdate and for getlastmodified.
<D:creationdate>2007-12-11T15:52:59Z</D:creationdate>
<D:getlastmodified>2007-12-11T16:50:46Z</D:getlastmodified>

Curios enough, IIS 6.0 without SharePoint gets it right, like
<a:creationdate b:dt="dateTime.tz">2007-07-13T09:57:32.109Z</a:creationdate>
<a:getlastmodified b:dt="dateTime.rfc1123">Fri, 13 Jul 2007 09:57:32 GMT</a:getlastmodified>

And so does Apache 2.2.3
<lp1:creationdate>2003-04-21T12:34:42Z</lp1:creationdate>
<lp1:getlastmodified>Mon, 21 Apr 2003 12:34:42 GMT</lp1:getlastmodified>

Because of this, it is necessary to try another parser when the first one fails, like in your patch. I will include it in the next version. As a minor change, I will reverse the order for creationdate, as to always try the RFC-conforming date-format first.

Until the next release, I suggest to apply the patch submitted by you.

Cheers
Werner