Incompatible time format in sitemap.xml

This is caused by the use of the constant DATE_W3C; I checked its definition, and I noticed that in PHP 5.x it is defined to be equal to 'Y-m-d\TH:i:sP'. Naturally, that is not desired value to use.

I will fix it in the development snapshot because it needs to be fixed first in the development snapshot, and then the code can be used to create another official version.

Thanks for pointing out this problem.

Hmm... That should work just fine actually. I'm also using define('DATE_W3C', 'Y-m-d\TH:i:sP'); in 6.x-2.x and my sitemap.xml is generating date formats like 2009-02-24T03:59:02+00:00. This needs some more investigation.

@Kiam: Your current define is using 'Y-m-d\TH:i:s+00:00'. It should probably be 'Y-m-d\TH:i:sP'.

Ok, I found what the problem is: According to PHP's date(), the 'P' format in date() was added in PHP 5.1.3, so we can't use that. Grr.

And there also appears to be a bug in PHP 5.1.1 and PHP 5.1.2 using the DATE_W3C constant:
http://bugs.php.net/bug.php?id=36599

This sounds exactly like the original problem. ulrich, which version of PHP are you using?

The code has been fixed in CVS.

The same fix must be done for the 6.x-2 branch, which uses the following code to set the date in the sitemap:

  $output .= '<lastmod>'. gmdate(DATE_W3C, $link['lastmod']) .'</lastmod>';

Your current define is using 'Y-m-d\TH:i:s+00:00'. It should probably be 'Y-m-d\TH:i:sP'.

That is at least compatible with the definition of time zone designator. I think that Google doesn't make any differences between +00:00, and Z; in the case it would complain about the +00:00, then I will change the definition of the XMLSITEMAP_DATE_W3C constant to 'Y-m-d\TH:i:s\Z'.

To notice that, as the date is generated from gmdate(), the time refers to the GMT time zone; there is no need to generate the last part dynamically, as we already know which time zone is.

I changed the definition of the custom constant used by the module in the 6.x-1 branch, and now it uses the Z, which has a slightly different meaning, and it is shorter.

Thanks again to ulrich for the report.

@Kiam/8: That's a good point. I'm going to change the 6.x-2.x define to define('DATE_W3C', 'Y-m-d\TH:i:s+00:00');. I'm not inclined however, to work around a *very* buggy PHP 5.1. That's a big reason why Drupal 7 is requiring PHP 5.2 instead of just PHP 5.0 or PHP 5.1.

@Kiam/9: The timestamps with /Z will now look like: 2009-05-04T23:56:17Z. Not correct at all. We should just use 'Y-m-d\TH:i:s+00:00' which is the format required by the protocol.

See the examples in http://www.w3.org/TR/NOTE-datetime; they clear report the following ones:

1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30 am, US Eastern Standard Time.
1994-11-05T13:15:30Z corresponds to the same instant.

The difference is slight, but the Z means that the time is UTC, while any other values would mean that the time is a local time that has a difference of hh hours, and mm minutes with UTC.

It's all to see what Google accepts; if it accepts also the Z, then there is no reason to not use it.

Ah. Got it! Let me know if Google verifies it!

I will surely do it. I think to add a secondary sitemap to my site written by hand, and see if Drupal says anything about the date format.

Google seems to accept the date format using the Z for the time zone descriptor; they accessed the additional sitemap I created, and reported the correct number of links present, but not any error about the incorrect (or unknown) date format.

I'm not inclined however, to work around a *very* buggy PHP 5.1.

The simpler way to resolve the problem is not use the DATE_W3C constant.

The constant is in PHP for this very purpose. It's not my fault that it's a bug that has been fixed over two years ago. As such, I am marking as fixed. I have also documented this in the 'Known Issues' section of the README.txt file in 6.x-2.x-dev. See http://drupal.org/cvs?commit=215670.

The constant is in PHP for this very purpose.

That is true, but it's also true that the constant is not of any use in versions of PHP before 5.1.3.
If the code must be compatible with PHP 4, then it will not use that constant, or create a constant with the same value; after all, Drupal 6 is compatible with PHP 4.

If all modules would require PHP 5, why would stay compatible with PHP 4?