epub check mentiones an error

[NASCARaddicted]

I know, epub checks have been discussed before, but still I want to mention it again

I have a public domain html file that I converted into xhtml 1.1 (it is valid). Then I converted it into epub with the latest edition of calibre (I always use the latest version). Then I let it run through an epub check (threepress.org which uses epub check 1.0.5)

Everything was o.k. except for 1 error:
ERROR: Rosenresli - Johanna Spyri.epub/content.opf(10): date value '2010-02-08T22:00:00' is not valid, YYYY[-MM[-DD]] expected

Member Netseeker told me that Dublin Core recommends the usage of either just the year (YYYY) or year+month (YYYY-MM) ...

So I edited line 10 of the content.opf and removed the time setting, so that only the 2010-02-08 was left - and now the epub file passed the epub check.

Is there a way how I can keep the time setting out of the convertion ? Or do I have to remove it every time, by myself ?

Thanks in advance

[kovidgoyal]

In this instance I happen to think that DC is wrong. There is no harm in storing extra information in the date field, as this can be useful for publications other than novels, like magazines/newspapers. So this is not going to change.

[kovidgoyal]

Oh and I just had a look at the OPF 2.0 spec. It does not require the date field to be restricted to only days and not times.

http://www.idpf.org/2007/opf/OPF_2.0...ec.html#TOC2.2

[wallcraft]

Originally Posted by kovidgoyal

It does not require the date field to be restricted to only days and not times.

I agree, this is a bug in epub check.

[rmm200]

In the interest of getting tool problems fixed - can one of you report it to EPubcheck?

Thanks!

Robert

[NASCARaddicted]

thanks for all the replies.

I was already surprised in the beginning, when epub check gave out this error, because in the past I learned that calibre and the ebooks its creates are very reliable.

[Jim Lester]

2010-02-08T22:00:00 is not valid either (no timezone)

[kovidgoyal]

According to the following links

if a timezone is omitted it is assumed to be a local time zone

http://www.cl.cam.ac.uk/~mgk25/iso-time.html#zone
http://en.wikipedia.org/wiki/ISO_8601#Times

[Jim Lester]

Originally Posted by kovidgoyal

According to the following links

if a timezone is omitted it is assumed to be a local time zone

http://www.cl.cam.ac.uk/~mgk25/iso-time.html#zone
http://en.wikipedia.org/wiki/ISO_8601#Times

The spec for W3C dates/datetime gives no such latitude. If you include time you must include timezone.

Valid W3C Formats from http://www.w3.org/TR/NOTE-datetime

Year:
YYYY (eg 1997)
Year and month:
YYYY-MM (eg 1997-07)
Complete date:
YYYY-MM-DD (eg 1997-07-16)
Complete date plus hours and minutes:
YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00)
Complete date plus hours, minutes and seconds:
YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00)
Complete date plus hours, minutes, seconds and a decimal fraction of a
second
YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00)

Besides, whose localtime, the creator's and if so what is the creator's localtime vs the consumer's localtime. For a long lived document, time without timezone is close to useless.

[kovidgoyal]

Writing timezones, is easy enough to do in calibre. Still wont fix the epubcheck problem though.

[Jim Lester]

Originally Posted by kovidgoyal

Writing timezones, is easy enough to do in calibre. Still wont fix the epubcheck problem though.

It'd be interesting to see if writing out a correct W3C date did indeed fix the problem. It wouldn't be surprising if an error message was more restrictive than the actual code is.

[kovidgoyal]

Well the next release of calibre will generate timezone info as well, so should be easy to check.

I have to say that accepting dates without timezones, but not dates+times without timezones is one of the more asinine things I have seen.

[pdurrant]

Originally Posted by kovidgoyal

I have to say that accepting dates without timezones, but not dates+times without timezones is one of the more asinine things I have seen.

Well, if you have a date without time zone you have the precise time +/- 24 hours. With timezone you have the precise time +/- 12 hours. So adding the time zone only makes the reference twice as precise.

Adding a time (hours:minutes) without time zone to a date only gives you the time to +/-12 hours. Then adding a time zone gives you the time +/- 30 seconds. So in this instance adding a time zone makes the reference 1440 times as precise.

Perhaps this explains why I've never seen a date given with a time zone....

[kovidgoyal]

An excellent analysis

But, looking at the W3C note, I see that date with timezone, but no time is actually illegal, which leads me to believe that the degree of accuracy improvement was not the motivation for this.

The W3C seems to believe that having an accurate date is just plain wrong and should be discouraged.