Hello Anton Thanks for reporting this problem and suggesting a workaround/solution. Can tey some alternative solutions than the one suggested in the stackoverflow thread.
Please read on. > Hello! > > Org-mode produces corrupted ODT files (date format does not pass the > validation). Details and patch: With the development version this is what I see in my "meta.xml". ,---- | <dc:date>2011-09-06T20:23:59+05:30</dc:date> `---- and I have confirmed that there are no errors reported by the Emacs's rng or online validators. > stackoverflow dot > com/questions/7299979/org-modes-odt-export-produces-corrupted-files/7304042 > With kindahero's hint the reason was found (odt validator): > ,---- > | upload:///test.odt/meta.xml[13,42]:Error:"2011-09-04T16:30:23%:z" does > | not satisfy the "dateTime" type > `---- > %:z is a typo in defun org-odt-format-date that produces wrong meta.xml. Atleast on my machine, I don't see %:z reproduced verbatim in the ouptut. I stole the "%:z" from the below thread in emacs-devel. http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg00262.html There is a mention that "%:z" is a "GNU extension". It looks like it is a portability issue. May I know what OS and what distribution of Emacs you are using? > Anyway, ODT standard requires another dateFormat: > 2011-09-04T16:30:23.12, i.e. including milliseconds and excluding > timezone offset. Well, actually the milliseconds portion is optional and timezone offset is definitely permitted. This is what 1.1 spec says ,---- | 3.1.9 Creation Date and Time | | The <meta:creation-date> element specifies the date and time when the | document was created initially. | | To conform with [xmlschema-2], the date and time format is | YYYY-MM-DDThh:mm:ss. | | 3.1.10 Modification Date and Time | | The <dc:date> element specifies the date and time when the document was | last modified. | | To conform with [xmlschema-2], the date and time format is YYYY-MM-DDThh:mm:ss. | | The name of this element was chosen for compatibility with the Dublin | Core. `---- ,---- http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dateTime | | 3.2.7.1 Lexical representation | | The ·lexical space· of dateTime consists of finite-length sequences of | characters of the form: | '-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?, where | [snip] | | '.' s+ (if present) represents the fractional seconds; | zzzzzz (if present) represents the timezone (as described below). | `---- > The following patch can be applied: > ...\org\contrib\lisp\org-odt.el, line 1576 (may differ), inside defun > org-odt-format-date (date): > (format-time-string "%Y-%m-%dT%T%:z"))))) > Replace with: > (format-time-string "%Y-%m-%dT%T.00"))))) I am able to see valid meta.xml with this change. But ... > Well, we've lost milliseconds (they aren't documented in > format-time-string) but passed the validation. Well if it is not documented then relying on it may not be a good idea. For example, I went with "%;z" which worked for me (and may be other users who are on GNU systems) but was broken for you. Does replacing (format-time-string "%Y-%m-%dT%T%:z") with (let ((stamp (format-time-string "%Y-%m-%dT%H:%M:%S%z"))) ;; no %z here (format "%s:%s" (substring stamp 0 -2) (substring stamp -2))) work for you. This is suggestion is from http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg00257.html Or Does replacing (format-time-string "%Y-%m-%dT%T%:z") with (format-time-string "%Y-%m-%dT%T") ;; no %:z here produce valid documents for you. > Word will still be unhappy with a new file, but after the online > validation and validation within Emacs, that's Word's problem. :-). Well, I have no access to Word. ps: Org permits #+DATE: declaration to contain either a user-provided date string or a format specifier. The use of these options is not recommended at (this point in time). For better portability, it is better that #+DATE is not-specified at all or if it is specified, the user has to be aware of the notes made above. There is a warning message that org-odt.el emits if user forces a date string. I am not sure how best this warning has attracted attention to itself. Jambunathan K. > Regards, > Anton > > --