This is very strange - at least I think it is!
I have a document with this:
<meta name="dc.date.created" content="2000-07-20">
Now that I have applied that patch to get use_doc_date to work, it's showing
up on the results page as 07-19-2000. All the dates seem to be one day off.
I've looked at the code for this in htdig/Retriever.cc and it looks
reasonable, plus since it assembles the day one digit at a time it seems
unlikely it could be turning 20 into 19.
I've also looked at the list of patches for 3.1.6 and don't see anything
related to this.
The only thing I can think of is some kind of timezone conversion - but why
that would be happening, I don't know.
Mont Vernon, NH
From: Jim Cole <greyleaf@yg...> - 2002-07-26 23:51:14
Janine Sisk's bits of Fri, 26 Jul 2002 translated to:
>I have a document with this:
><meta name="dc.date.created" content="2000-07-20">
>Now that I have applied that patch to get use_doc_date to work, it's showing
>up on the results page as 07-19-2000. All the dates seem to be one day off.
The dc.date.* content is interpreted as if it were a
Last-Modified header. As such, the GMT time zone is assumed.
Furthermore, since only the date is specified, a time of 00:00:00
is used as a default. When the resulting date/time is displayed,
it is converted to a local time zone. If you were to enable the
iso_8601 attribute, you would see that the time differs from
2000-07-20T00:00:00 by the number of hours your time zone differs
from GMT. Since you are, presumably, in the western hemisphere,
that pushes the date back to the previous day.
In order to correct the problem, you should convert the local
document creation date to GMT and use that date as the content.
If you add the time, ht://Dig expects it to be in the form
"YYYY-MM-DD HH:MM:SS" (trailing time components are optional if
you don't want to use minutes and/or seconds). I am not sure that
this format is correct according to Dublin Core, or even
according to ISO 8601 for that matter, but that is what the code
> The only thing I can think of is some kind of timezone conversion - but
> that would be happening, I don't know.
Dates returned from the server are expected to be in terms of GMT. So as
you've specified it, it's midnight GMT, which in your Central timezone
is "the day before." There doesn't seem to be a great way of resolving
this last time it was discussed, IIRC. The problem is that some servers
return local timezones and you often don't have a timezone specified.
Since htdig will also read optional hh:mm:ss, you might try adding this
Williams Students Online