search

resync / resync-simulator

ResourceSync Change Simulator
11 stars 6 forks source link

Fix handling of timezones in lastmod #14

Closed zimeon closed 12 years ago

zimeon commented 12 years ago

I propose that we should:

  1. Have the timestamp in Resource be in UTC.
  2. Output of lastmod should use the YYYY-MM-DDTHH:MM:SSZ notation
  3. Input code for reading lastmod values should correctly handle timezones. Should assume 00:00:00 UTC for time portion if a date with no time information is specified.

I note that Sitemaps.org says that lastmod must follow the W3C spec (http://www.w3.org/TR/NOTE-datetime) which says that there must be a timezone (either Z or +/-hh:mm) if there is a time component. Thus time component without timezone info is an error.

behas commented 12 years ago

Sitemap.org says:

lastmod optional

The date of last modification of the file. This date should be in W3C Datetime format. This format allows you to omit the time portion, if desired, and use YYYY-MM-DD. Note that this tag is separate from the If-Modified-Since (304) header the server can return, and search engines may use the information from both sources differently.

I agree with your proposal. ResourceSync sitemaps should/must use UTC notation with time, which practically means that APIs must take care of that kind of conversion.

I think with this restriction we put some burden on clients/sources but we gain a lot because we can sync based on dates only without messing around with timezones.

zimeon commented 12 years ago

Code now follows the W3CDatetime. Resource.py rejects a datetime without timezone info, accepts date and assumes 00:00:00Z time for it.