org dates are not correctly exported to dates in odt

[ouboub]

Hi

while I have no problem exporting org-tables with org-dates to ods, when I try to export an org document with org-dates and dates in org-tables, they are not exported correctly. I attach an org file, with the exported odt, and ods converted versions. I am sure I miss something, but can't remember what. regards Uwe Brauer Date-Prob.zip

[kjambunathan]

I have pushed a fix.

I remember we having some discussion about locale-specific rendering of date in gnumeric / libreoffice calc, and some of the decisions I made in regards to date style were influenced by that decision. I don't recall the precise details on the go ...

As this bug illustrates, the formatting of date fields affects both ODT and ODS export.

If you want locale-specific rendering in ODT export then flip number:automatic-order to false here

https://github.com/kjambunathan/org-mode-ox-odt/blob/433c3c938f3327b778a2a1d4b18aab6d011f5d8e/lisp/ox-odt.el#L3546

There may be other places where the date style might be using automatic ordering of date fields. (Automatic ordering means, the ordering is affected by the LOCALE of your LIBREOFFICE INSTALLATION and not the LOCALE of EMACS or its customizations)

Let me know what you find wrt inconsisten behaviours in date fields and date styles.

Keep the bug open, I will audit date related styles at my own pace. But ... if you run in to date related issues as part of your regular workflow, and if you point out the problematic instances with a reproducible example, I can fix them right away.

[ouboub]

Hi thanks for the quick fix, I played with it but even with

I always obtain the format 26/07/2023 while I would prefer 26.07.2023 as in the ods export. In the attached example you can see that I tried to play also with the variables

(org-time-stamp-custom-formats

etc. The strange thing is that I can edit the date format in the converted document to german, but of course if I have many data fields that is cumbersome. Not sure who is the culprit here (because the ods files are fine) Date-Prob.zip

[kjambunathan]

I always obtain the format 26/07/2023 while I would prefer 26.07.2023 as in the ods export.

You aren't saying if you flipped the following boolean locally or not ...

In this line https://github.com/kjambunathan/org-mode-ox-odt/blob/433c3c938f3327b778a2a1d4b18aab6d011f5d8e/lisp/ox-odt.el#L3546 change true to false.

Once you flip that boolean locally, your ODT is fine, but ODS has issues, right?

(I have trouble grasping what you are saying, and you may have to re-state what you are saying)

[kjambunathan]

Try flipping the value of automatic-order in the following places

https://github.com/search?q=repo%3Akjambunathan%2Forg-mode-ox-odt+number%3Aautomatic-order+path%3A%2F%5Eetc%5C%2Fstyles%5C%2F%2F&type=code

[kjambunathan]

This is how you identify the styles that would be of interest to you:

In the content.xml of ods file search for date of interest, say C-s 2023.

	    <table:table-cell office:date-value="2023-07-26T00:00:00"
			      office:value-type="date"
			      table:style-name="OrgTableCellTDate">
	      <text:p text:style-name="OrgTableContentsLeft"></text:p>
	    </table:table-cell>

The style you see is OrgTableCellTDate

If you search for the above style in content.xml AND styles.xml you will see

    <style:style style:name="OrgTableCellTDate"
		 style:parent-style-name="OrgTableCellT"
		 style:family="table-cell"
		 style:data-style-name="OrgDateStyle" />

You can see two styles OrgTableCellT and OrgDateStyle.

OrgTableCellT is like this

    <style:style style:name="OrgTableCellT"
		 style:family="table-cell">
      <style:table-cell-properties fo:border-bottom="none"
				   fo:border-left="none"
				   fo:border-right="none"
				   fo:border-top="0.002cm solid #000000"
				   fo:padding="0.159cm" />
    </style:style>

and

OrgDateStyle is like this

    <number:date-style style:name="OrgDateStyle"
                       number:automatic-order="true">
      <number:day number:style="long" />
      <number:text>/</number:text>
      <number:month number:style="long" />
      <number:text>/</number:text>
      <number:year />
    </number:date-style>

and defined in styles.xml.

... and it has automatic-order ON.

And OrgDateStyle comes from the factory styles which is located in one of the xml files under styles

~/src1/org-mode-ox-odt/master/etc/styles$  tree .
.
├── ods
│   ├── content.xml
│   ├── META-INF
│   │   └── manifest.xml
│   ├── meta.xml
│   ├── mimetype
│   ├── OrgOdsTemplate.ots
│   └── styles.xml
├── OrgOdtContentTemplate.xml
├── OrgOdtStyles.xml
└── README

3 directories, 9 files

The root directory has odt styles, and the ods subdir has ods styles.

So to get the output you desired flip the automatic-order of number:automatic-order in OrgDateStyle. I need to check if the style definition of OrgDateStyle is influenced by the custom date formats. I believe it is not.

[kjambunathan]

Based on the above notes, this is a possible fix for your problem ...

In https://github.com/kjambunathan/org-mode-ox-odt/blob/433c3c938f3327b778a2a1d4b18aab6d011f5d8e/etc/styles/ods/styles.xml#L75

change

  <number:date-style style:name="OrgDateStyle" number:automatic-order="true">
    <number:day number:style="long" />
    <number:text>/</number:text>
    <number:month number:style="long" />
    <number:text>/</number:text>
    <number:year />
  </number:date-style>

to

  <number:date-style style:name="OrgDateStyle"
		     >
    <number:month number:style="long" />
    <number:text>.</number:text>
    <number:day number:style="long" />
    <number:text>.</number:text>
    <number:year />
    </number:date-style>

In the re-written styles, I have

• turned OFF automatic-order
• Change the field separator from / to .
• re-arranged the date fields so that month comes first etc.

Experiment with this fix "by hand", and if it works for you

• I will add support for custom in buffer nxml styles for ods export
• Make sure that OrgDateStyle is based on custom fields

Waiting for your feedback ...

[kjambunathan]

Make sure that OrgDateStyle is based on custom fields

OrgDate1 and OrgDate2 in content.xml use the styles defined in custom date formats.

    <number:date-style style:name="OrgDate1"
                       number:automatic-order="true"
                       number:format-source="fixed">
      <number:day number:style="long" />
      <number:text>.</number:text>
      <number:month number:style="long" />
      <number:text>.</number:text>
      <number:year number:style="long" />
    </number:date-style>
    <number:date-style style:name="OrgDate2"
                       number:automatic-order="true"
                       number:format-source="fixed">
      <number:day number:style="long" />
      <number:text>.</number:text>
      <number:month number:style="long" />
      <number:text>.</number:text>
      <number:year number:style="long" />
      <number:text></number:text>
      <number:hours number:style="long" />
      <number:text>:</number:text>
      <number:minutes number:style="long" />
    </number:date-style>

So copy OrgDate1 from content.xml of an exported ODS file, to <whatever>/org-mode-ox-odt/master/etc/styles/ods/styles.xml, and rename it to OrgDateStyle. Make sure that the automatic-order is off. (Remember to replace the stock OrgDateStyle)

OrgDate1 is date only format. OrgDate2 is date-and-time format.

[ouboub]

I always obtain the format 26/07/2023 while I would prefer 26.07.2023 as in the ods export.

You aren't saying if you flipped the following boolean locally or not ...

In this line https://github.com/kjambunathan/org-mode-ox-odt/blob/433c3c938f3327b778a2a1d4b18aab6d011f5d8e/lisp/ox-odt.el#L3546 change true to false.

Once you flip that boolean locally, your ODT is fine, but ODS has issues, right?

(I have trouble grasping what you are saying, and you may have to re-state what you are saying)

Sorry I wrote that to hastly. I set the value to false, that is

	      (concat " number:automatic-order=\"false\""

and recompiled

but the date format in the odt document still was not changed, but remained 26/07/2023 the exported ods file is ok. I just see that you sent a couple of other posts so I will try them out.

[ouboub]

Based on the above notes, this is a possible fix for your problem ...

In

https://github.com/kjambunathan/org-mode-ox-odt/blob/433c3c938f3327b778a2a1d4b18aab6d011f5d8e/etc/styles/ods/styles.xml#L75

change

  <number:date-style style:name="OrgDateStyle" number:automatic-order="true">
    <number:day number:style="long" />
    <number:text>/</number:text>
    <number:month number:style="long" />
    <number:text>/</number:text>
    <number:year />
  </number:date-style>

to

  <number:date-style style:name="OrgDateStyle"
		     >
    <number:month number:style="long" />
    <number:text>.</number:text>
    <number:day number:style="long" />
    <number:text>.</number:text>
    <number:year />
    </number:date-style>

In the re-written styles, I have

• turned OFF automatic-order
• Change the field separator from / to .
• re-arranged the date fields so that month comes first etc.

Experiment with this fix "by hand", and if it works for you

• I will add support for custom in buffer nxml styles for ods export
• Make sure that OrgDateStyle is based on custom fields

Waiting for your feedback ...

I did the change you recommend, but it seemed not to have helped, attached you find the results

I will now try out your last recommendation Date-Prob.zip

[kjambunathan]

and recompiled but the date format in the odt document still was not changed, but remained 26/07/2023

Did you reload the compiled file .. open the xml files in the zip file and see if the automatic-order is indeed false. It seems OK on my side.

The reason I am asking to check at your end is there is a subtle interaction between the locale setting on the styles file, and locale setting of your libreoffice installation. What I mean is much of what you see will depend on NOT just the Emacs config, but the LibreOffice config at your side. (Your libreoffice is on spanish or german locale, and mine is on Indian locale)

Try exporting the following snippet to ods and tell me what you see ... Remember execute the elisp block .... It rewrites your config .... You should see custom time format in ODS sheet .

#+begin_src emacs-lisp :results silent :exports none
  (custom-set-variables
   '(org-display-custom-times t)
   '(org-time-stamp-custom-formats '("%d..%m..%Y" . "%d..%m..%Y %I:%M"))
   '(org-odt-use-date-fields t))

  (let* (
       (custom-time-fmts
	(if org-display-custom-times
	    (cons (org-time-stamp-format (not 'with-time) 'no-brackets 'custom)
		  (org-time-stamp-format 'with-time 'no-brackets 'custom))
	  '("%Y-%M-%d %a" . "%Y-%M-%d %a %H:%M"))))
  (setq org-odt-extra-styles
	(concat (or (when (boundp 'org-odt-extra-styles)
		      (get 'org-odt-extra-styles 'saved-value))
		    "")
		"\n\n"
		(string-join
		 (list
		  ;; - Dump date-styles.
		  (or (concat (org-odt--build-date-styles (car custom-time-fmts)
							  "OrgDateStyle")
			      ;; (org-odt--build-date-styles (cdr custom-time-fmts)
			      ;; 				  "OrgDate2")
			      )
		      ""))
		 "\n")))
  )
#+end_src

<2020-05-01 vie>

* Acount  <2020-05-01 vie>

| / |      <> | <>           |
|   | Account | Date         |
|---+---------+--------------|
|   |       2 | <2023-07-26> |
|   |       3 |              |
|   |         |              |
#+TBLFM: 

Or maybe <2023-07-26>

The snippet above uses

• double dots for separator
• introduces a OrgDateStyle based on the customization by modifying org-odt-extra-styles.

Once you have checked the ODS export you can undo the effect of above snippet with

(setq org-odt-extra-styles nil)

I just see that you sent a couple of other posts so I will try them out.

They are notes to myself. There is no need for you to read them ...

[ouboub]

and recompiled but the date format in the odt document still was not changed, but remained 26/07/2023

Did you reload the compiled file .. open the xml files in the zip file and see if the automatic-order is indeed false. It seems OK on my side.

after the change the the recompilation I restarted emacs then in the relvant xml files I see

    <number:date-style style:name="OrgDate1" number:automatic-order="false" number:format-source="fixed">
      <number:day number:style="long"/>
      <number:text>/</number:text>
      <number:month number:style="long"/>
      <number:text>/</number:text>
      <number:year number:style="long"/>
    </number:date-style>
    <number:date-style style:name="OrgDate2" number:automatic-order="false" number:format-source="fixed">
      <number:day number:style="long"/>
      <number:text>/</number:text>
      <number:month number:style="long"/>
      <number:text>/</number:text>
      <number:year number:style="long"/>
      <number:text> </number:text>
      <number:hours number:style="long"/>
      <number:text>:</number:text>
      <number:minutes number:style="long"/>
      <number:text> </number:text>
      <number:am-pm/>
    </number:date-style>

The reason I am asking to check at your end is there is a subtle interaction between the locale setting on the styles file, and locale setting of your libreoffice installation. What I mean is much of what you see will depend on NOT just the Emacs config, but the LibreOffice config at your side. (Your libreoffice is on spanish or german locale, and mine is on Indian locale)

Try exporting the following snippet to ods and tell me what you see ... Remember execute the elisp block .... It rewrites your config .... You should see custom time format in ODS sheet .

#+begin_src emacs-lisp :results silent :exports none
  (custom-set-variables
   '(org-display-custom-times t)
   '(org-time-stamp-custom-formats '("%d..%m..%Y" . "%d..%m..%Y %I:%M"))
   '(org-odt-use-date-fields t))

  (let* (
       (custom-time-fmts
	(if org-display-custom-times
	    (cons (org-time-stamp-format (not 'with-time) 'no-brackets 'custom)
		  (org-time-stamp-format 'with-time 'no-brackets 'custom))
	  '("%Y-%M-%d %a" . "%Y-%M-%d %a %H:%M"))))
  (setq org-odt-extra-styles
	(concat (or (when (boundp 'org-odt-extra-styles)
		      (get 'org-odt-extra-styles 'saved-value))
		    "")
		"\n\n"
		(string-join
		 (list
		  ;; - Dump date-styles.
		  (or (concat (org-odt--build-date-styles (car custom-time-fmts)
							  "OrgDateStyle")
			      ;; (org-odt--build-date-styles (cdr custom-time-fmts)
			      ;; 				  "OrgDate2")
			      )
		      ""))
		 "\n")))
  )
#+end_src

<2020-05-01 vie>

* Acount  <2020-05-01 vie>

| / |      <> | <>           |
|   | Account | Date         |
|---+---------+--------------|
|   |       2 | <2023-07-26> |
|   |       3 |              |
|   |         |              |
#+TBLFM: 

Or maybe <2023-07-26>

The snippet above uses

• double dots for separator
• introduces a OrgDateStyle based on the customization by modifying org-odt-extra-styles.

Once you have checked the ODS export you can undo the effect of above snippet with

(setq org-odt-extra-styles nil)

I just see that you sent a couple of other posts so I will try them out.

They are notes to myself. There is no need for you to read them ...

I did this also and I see in the ods file 07.26.23

[kjambunathan]

For ods what matters is the value of OrgDateStyle.

For odt what matters are the values of OrgDate1 and OrgDate2.

The XML files generated by the exporter is one long line. I am surprised how you could get a pretty printed xml so fast. Surely you are using a tool other than Emacs to view XML files. What is it?

[ouboub]

For ods what matters is the value of OrgDateStyle.

For odt what matters are the values of OrgDate1 and OrgDate2.

The XML files generated by the exporter is one long line. I am surprised how you could get a pretty printed xml so fast. Surely you are using a tool other than Emacs to view XML files. What is it?

xmllint --format content.xml > content2.xml

[kjambunathan]

A quck tip ...

ODT exporter uses tidy for pretty printing.

Use M-x apropos-option odt prett

to identify the variable

Or

C-c C-e # o

to change the per buffer option

(Pretty printing is only for debugging.)

I will make some elisp changes su that debugging and experimentation becomes easy ...

I will message once that is done

On Wed, 26 Jul, 2023, 10:13 pm Uwe Brauer, @.***> wrote:

For ods what matters is the value of OrgDateStyle.

For odt what matters are the values of OrgDate1 and OrgDate2.

The XML files generated by the exporter is one long line. I am surprised how you could get a pretty printed xml so fast. Surely you are using a tool other than Emacs to view XML files. What is it?

xmllint --format content.xml > content2.xml

— Reply to this email directly, view it on GitHub https://github.com/kjambunathan/org-mode-ox-odt/issues/244#issuecomment-1652163472, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEXTBKD76AOAIHCWFTH6WALXSFCLPANCNFSM6AAAAAA2YCSN3A . You are receiving this because you modified the open/close state.Message ID: @.***>

[ouboub]

I run another check. in bash I run LANG=de_DE.UTF-8 LANGUAGE=de_DE.UTF-8 I started swriter (7,2) indeed german is the default language as the attached screenshots shows. But opening the converted odt the dates are displayed by english/american standard, so switching back to german solves the issue. BTW, any chance to get rid of the < > as in the ods exporter?

[ouboub]

BTW, any chance to get rid of the < > as in the ods exporter?

Sorry my bad, the < > are deleted when exported, I just did not do it properly, the English date problem still persists, though

[kjambunathan]

Remember the factory styles were generated on my machine and it is en_IN (essentially british conventions)

So the locale for automatic order could be picked from many places .... I don't have clarity on what is happening, and it requires experimentation or further research

I understand that you are more interested in not having brackets than doing doing date math on date objects with Calc. That is. Date as a simple string in Calc is good enough for you

I have a patch ready and I am polishing it. You will be able to strip or not strip the brackets

You will hear from me soon ...

Irrespective of you immediate needs, I would encourage you to experiment with date fields

On Mon, 31 Jul, 2023, 12:30 pm Uwe Brauer, @.***> wrote:

BTW, any chance to get rid of the < > as in the ods exporter?

Sorry my bad, the < > are deleted when exported, I just did not do it properly, the English date problem still persists, though

— Reply to this email directly, view it on GitHub https://github.com/kjambunathan/org-mode-ox-odt/issues/244#issuecomment-1657782249, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEXTBKDLMGQ5PURCVGG6A3LXS5JYFANCNFSM6AAAAAA2YCSN3A . You are receiving this because you modified the open/close state.Message ID: @.***>

[kjambunathan]

A note to future me ...

Date fields have been in ODT exporter forever. I think I implemented with the assumption that one can click on it and subsequently modify it with a Libreoffice calendar widget.

The recent experimentations shows that with both and ODT and ODS, having a calendar widget pop up is not a default action. It requiers further configuration or installing additional extensions.

I strongly remember that if one is designing forms (human fillable forms that you submit to the bureaucratic machinery) it is possible to have calendar control pop up on clicking the date field.

In other words, the only advantage of date field that I see is math on dates with Calc. And if your or my use-case doesn't involve much math with date or date time objects, then date as a string works admirably with less head-scratching.

What I am saying is one can get by without date fields, ... but I want to have date fields around (and experiment with it) with the hope that exporter will continue to grow in useful ways.

[ouboub]

"JK" == Jambunathan K @.***> writes:

Remember the factory styles were generated on my machine and it is en_IN (essentially british conventions)

So the locale for automatic order could be picked from many places .... I don't have clarity on what is happening, and it requires experimentation or further research

I understand that you are more interested in not having brackets than doing doing date math on date objects with Calc. That is. Date as a simple string in Calc is good enough for you

I have a patch ready and I am polishing it. You will be able to strip or not strip the brackets

Thanks, just to make that entirely clear. If I use

#+begin_src emacs-lisp :results silent :exports none
(defun org-odt-timestamp (timestamp contents info)
 "Transcode a TIMESTAMP object from Org to ODT.
CONTENTS is nil.  INFO is a plist used as a communication
channel."
  (let* ((_raw-value (org-element-property :raw-value timestamp))
	 (type (org-element-property :type timestamp)))
    (if (not (plist-get info :odt-use-date-fields))
	(let ((value (org-odt-plain-text
		      (org-timestamp-translate timestamp) info)))
	  (cl-case (org-element-property :type timestamp)
	    ((active active-range)
	     (format "<text:span text:style-name=\"%s\">%s</text:span>"
		     "OrgActiveTimestamp" value))
	    ((inactive inactive-range)
	     (format "<text:span text:style-name=\"%s\">%s</text:span>"
		     "OrgInactiveTimestamp" value))
	    (otherwise value)))
      (cl-case type
	(active
	 (format "<text:span text:style-name=\"%s\">%s</text:span>"
		 "OrgActiveTimestamp"
		 (format "%s" (org-odt--format-timestamp timestamp))))
	(inactive
	 (format "<text:span text:style-name=\"%s\">%s</text:span>"
		 "OrgInactiveTimestamp"
		 (format "%s" (org-odt--format-timestamp timestamp))))
	(active-range
	 (format "<text:span text:style-name=\"%s\">%s</text:span>"
		 "OrgActiveTimestamp"
		 (format "%s&#x2013;%s"
			 (org-odt--format-timestamp timestamp)
			 (org-odt--format-timestamp timestamp 'end))))
	(inactive-range
	 (format "<text:span text:style-name=\"%s\">%s</text:span>"
		 "OrgInactiveTimestamp"
		 (format "%s&#x2013;%s"
			 (org-odt--format-timestamp timestamp)
			 (org-odt--format-timestamp timestamp 'end))))
	(otherwise
	 (format "<text:span text:style-name=\"%s\">%s</text:span>"
		 "OrgDiaryTimestamp"
		 (org-odt-plain-text (org-timestamp-translate timestamp)
				     info)))))))

#+end_src

Then the exported odt, has no brackets.

What really puzzles me.

1. I open an empty odt file with swriter: default language is German.

2. I open the odt which was converted from org, and the default
   language is English. So just switching that back to German solves
   my problem. So does this mean the org dates have been translated
   to data fields (sorry I use odt basically to interchange
   documents with colleagues, I almost never use it for writing, I
   prefer emacs and your converter).

You will hear from me soon ...

Irrespective of you immediate needs, I would encourage you to experiment with date fields

On Mon, 31 Jul, 2023, 12:30 pm Uwe Brauer, @.***> wrote:

BTW, any chance to get rid of the < > as in the ods exporter?

Sorry my bad, the < > are deleted when exported, I just did not do it properly, the English date problem still persists, though

— Reply to this email directly, view it on GitHub https://github.com/kjambunathan/org-mode-ox-odt/issues/244#issuecomment-1657782249, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEXTBKDLMGQ5PURCVGG6A3LXS5JYFANCNFSM6AAAAAA2YCSN3A . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Warning: Content may be disturbing to some audiences I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the NATO membership of the Ukraine. I support the EU membership of the Ukraine. https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

[kjambunathan]

issue-244-timestamps-unit-test.zip

---

To get this

do this

#+odt_preferred_output_format: pdf

# #+ODT_PRETTIFY_XML: tidy+indent

#+ATTR_ODT: :style "GriddedTable"
#+ATTR_ODT: :widths "1,1"
#+CAPTION: simple
| <2023-08-02 Wed> | <2023-08-02 Tue 20:00-22:00> |

#+name: customize
#+begin_src emacs-lisp :results silent :exports results
  (require 'ox-ods)
  (custom-set-variables
   '(org-display-custom-times t)
   '(org-time-stamp-custom-formats '("%d-##-%m-##-%Y" . "%d-##-%m-##-%Y %I-**-%M"))
   ;; Dates as text
   '(org-odt-timestamp-options '( :strip-brackets-around-date t
				  :emit-date-as-date-field nil
				  :emit-date-as-date-object nil
				  :number:date-style-attributes
				  ( :number:automatic-order nil)))
   )
#+end_src

#+name: settings
#+begin_src emacs-lisp :exports results
  `(
    ,@`(
	(org-time-stamp-formats ,org-time-stamp-formats)
	(org-display-custom-times ,org-display-custom-times)
	(org-time-stamp-custom-formats ,org-time-stamp-custom-formats)
	)
    ,@'((org-odt-timestamp-options))
    ,@(seq-map
       (lambda (it)
	 (list it (plist-get org-odt-timestamp-options it))
	 )
       '( :strip-brackets-around-date
	  :emit-date-as-date-field
	  :emit-date-as-date-object
	  :number:date-style-attributes)))
#+end_src

#+caption: Settings
#+ATTR_ODT: :style "GriddedTable"
#+ATTR_ODT: :widths "8,10"
#+RESULTS: settings
| org-time-stamp-formats        | (%Y-%m-%d %a . %Y-%m-%d %a %H:%M)          |
| org-display-custom-times      | t                                          |
| org-time-stamp-custom-formats | (%d-##-%m-##-%Y . %d-##-%m-##-%Y %I-**-%M) |
| org-odt-timestamp-options     |                                            |
| :strip-brackets-around-date   | t                                          |
| :emit-date-as-date-field      | nil                                        |
| :emit-date-as-date-object     | nil                                        |
| :number:date-style-attributes | (:number:automatic-order nil)              |

* COMMENT Complex Examples <2023-08-01 Tue>

#+ATTR_ODT: :style "GriddedTable"
#+ATTR_ODT: :rel-width 100
#+CAPTION: Table with Timestamps
| <2006-11-01 Wed>                   | [2006-11-01 Wed]                   |
| <2006-11-01 Wed 19:15>             | [2006-11-01 Wed 19:15]             |
| <2006-11-02 Thu 20:00-22:00>       | [2006-11-02 Thu 20:00-22:00]       |
| <2007-05-16 Wed 12:30 +1w>         | [2007-05-16 Wed 12:30 +1w]         |
| <%%(diary-float t 4 2)>            | [%%(diary-float t 4 2)]            |
| <2004-08-23 Mon>--<2004-08-26 Thu> | [2004-08-23 Mon]--[2004-08-26 Thu] |
| <2005-10-01 Sat +1m>               | [2005-10-01 Sat +1m]               |
| <2005-10-01 Sat +1m -3d>           | [2005-10-01 Sat +1m -3d]           |
| <2008-02-10 Sun ++1w>              | [2008-02-10 Sun ++1w]              |
| <2008-02-08 Fri 20:00 ++1d>        | [2008-02-08 Fri 20:00 ++1d]        |
| <2005-11-01 Tue .+1m>              | [2005-11-01 Tue .+1m]              |
| <2019-04-05 08:00 Fri .+1h>        | [2019-04-05 08:00 Fri .+1h]        |

** Plain timestamp;
  <2006-11-01 Wed 19:15>

** Plain timestamp; Event; Appointment
  <2006-11-02 Thu 20:00-22:00>

** Timestamp with repeater interval
  <2007-05-16 Wed 12:30 +1w>

** 22:00-23:00 Diary-style expression entries
  <%%(diary-float t 4 2)>

** Time/Date range
   <2004-08-23 Mon>--<2004-08-26 Thu>

** Inactive timestamp
  [2006-11-01 Wed]

** TODO Repeater
   DEADLINE: <2005-10-01 Sat +1m>

** TODO Repeater and Warning
   DEADLINE: <2005-10-01 Sat +1m -3d>

** TODO Special Repeater 1
   DEADLINE: <2008-02-10 Sun ++1w>

   Marking this DONE shifts the date by at least one week, but also
   by as many weeks as it takes to get this date into the future.
   However, it stays on a Sunday, even if you called and marked it
   done on Saturday.

** TODO Special Repeater 2
   DEADLINE: <2008-02-08 Fri 20:00 ++1d>

Marking this DONE shifts the date by at least one day, and also
   by as many days as it takes to get the timestamp into the future.
   Since there is a time in the timestamp, the next deadline in the
   future will be on today's date if you complete the task before
   20:00.

** TODO Special Repeater 3
   DEADLINE: <2005-11-01 Tue .+1m>

   Marking this DONE shifts the date to one month after today.

** TODO Special Repeater 4
   DEADLINE: <2019-04-05 08:00 Fri .+1h>

   Marking this DONE shifts the date to exactly one hour from now.

#+odt_extra_styles: <style:style style:name="OrgActiveTimestamp"
#+odt_extra_styles:              style:parent-style-name="OrgTimestamp"
#+odt_extra_styles:              style:family="text">
#+odt_extra_styles:   <style:text-properties fo:background-color="transparent"
#+odt_extra_styles: 			 fo:color="#ff0000" />
#+odt_extra_styles: </style:style>
#+odt_extra_styles: <style:style style:name="OrgInactiveTimestamp"
#+odt_extra_styles:              style:parent-style-name="OrgTimestamp"
#+odt_extra_styles:              style:family="text">
#+odt_extra_styles:   <style:text-properties fo:background-color="transparent"
#+odt_extra_styles: 			 style:use-window-font-color="true" />
#+odt_extra_styles: </style:style>

[kjambunathan]

Leave the issue open.

• I have to update the docstring
• amend the commit message.
• report a bug in libreoffice calc

[kjambunathan]

May be clocktables are good candidates for exporting to ODS.
See Org Mode: Exporting Clock Tables

Specifically this line

The problem is that my employer wants the report to be in a specific format.

This essentially means using custom display of date/date time and duration.

It is good to mentally run through the above case, and see if certain ox-ods functionalities could be tested against or improved.

[ouboub]

"JK" == Jambunathan K @.***> writes:

issue-244-timestamps-unit-test.zip

To get this

do this

I pull the latest commits, run

Make clean make

Restarted emacs

Unzipped the attached zip.

Exported to odt, was puzzled at first, changed then the setting back to my preferred

'(org-time-stamp-custom-formats '("%d.%m.%Y" . "%d.%m.%Y %I:%M"))

Exported again, and the result looks as I expected, but the date no longer is a date field, which is fine for me

I played around a bit with

:emit-date-as-date-object t ; not sure that does

Not sure that the last variable is supposed to do. In any case, thanks for that solution. It will be helpful in my workflow.

regards

[kjambunathan]

Exported to odt, was puzzled at first, changed then the setting back to my preferred

'(org-time-stamp-custom-formats '("%d.%m.%Y" . "%d.%m.%Y %I:%M"))

It is just a format string, you can put whatever you want. I added an exotic format with fancy separator to check if the OrgDate and OrgDateAndTime styles are kicking in. In the org snippet, the date goes as literal text ... so the date styles have no bearing.

and the result looks as I expected, but the date no longer is a date field, which is fine for me

If someone needs date arithmetic on spreadsheet it would come in handy.

Many of these knobs are meant for me, and they would allow further experimentation.