[bug?, ox-odt] Format DATE

[bug?, ox-odt] Format DATE

[Rasmus]

Hi,

ox-odt.el ignores `org-export-date-timestamp-format'.

Instead, it uses a variable `org-odt-use-date-fields', which maps
/all/ dates to the styles "OrgDate1" and "OrgDate2".  I'm not sure if
these are meant to be customizable or not.  In LO I'm able to change
the style by clicking on the timestamp so probably the style has to be
specified that way, somehow.

Unfortunately, the undocumented `org-odt--format-timestamp' does not
seem to support alternative formats, but again, this may be due to
fact that dates are formatted in LO.

I /might/ have time to look at this myself over the weekend, unless
someone knows how to fix it.

—Rasmus

-- 
May contains speling mistake

Re: [bug?, ox-odt] Format DATE

[Christian Moe]

[Forgot to "reply all", so part of the below discussion happened
off-list. Sorry. Back on track now. CM]

Rasmus writes:

> Hi Christian,
>
> Thanks for the helpful email.  Note that you did not sent it to the
> ML, though.
>
> Christian Moe <mail@christianmoe.com> writes:
>
>> Going by the documentation of org-odt-use-date-fields, the data styles
>> "OrgDate1" and "OrgDate2" are supposed to be mapped from
>> org-time-stamp-custom-formats, rather than
>> org-export-date-timestamp-format. 
>
> Yeah, I saw that, but the description of
> `org-time-stamp-custom-formats' looks a bit opaque.  I wondered if it
> would affect the recognition of timestamps in buffer (since the
> variable is not an org-export-· variable).  If it's truly *only*
> affecting exports it should be renamed.

No, judging by the manual entry, it was intended for customizing the
appearance of timestamps in the buffer, which it does, see below. To
accommodate people who think ISO time format is just too darned
/sensible/...

But it has the nice (and little-mentioned) side effect that you can use
it to change the appearance of timestamps in exports, where
non-geeky-looking everyday-language dates are often comme il faut. Works
nicely in HTML, for instance, except that you still get geeky-looking
brackets around the dates (may need a filter to remove those).

It's nice, for instance, if you have a document with a lot of dates in a
European format and need to switch to an American format; you can do it
by changing a setting.

And the ODT exporter builds on this to give date fields that can be
further changed in LibreOffice.

>> So this will apply to the output from the DATE keyword too.
>>
>> To make this happen, org-display-custom-times must be non-nil. 
>> This affects not only the date in the heading from the DATE keyword,
>> but also all other timestamps in the document.
>>
>> Having org-display-custom-times turned on all the time also puts
>> overlays on the timestamps in your buffer, but if this annoys you you
>> can bind it to be set during export only.
>
> OK.  I don't know this functionality.  It sounds less bad that what I
> feared, but still the org-export-· variables should probably be
> sufficient.
>
> Is `org-time-stamp-custom-formats' the recommend way of formatting
> regular time stamps for export?

I don't know about "recommended". It doesn't seem to be documented for
export at all. And as for ODT, the code comments say the feature
translating from custom time stamp formats to ODT date styles is
"experimental". Seems to work OK, though.

>> But doing it this way still ignores
>> org-export-date-timestamp-format, and any solution based on copying that
>> variable into org-time-stamp-custom-formats makes unsafe assumptions about
>> user preferences.
>
> Yes.
>
>> It seems to me that the export of the DATE keyword ought to honor a
>> non-nil org-export-date-timestamp-format, whether or not the user is
>> applying custom formatting to other timestamps. 
>> But that would take some
>> changes to several parts of ox-odt.el, I think.
>
> Yeah.  It's can be made even more complicated than that, since the
> *document language* of the output also affects how dates are
> formatted. . .

In Org, or in LibreOffice once you set the language there? If the
#+LANGUAGE keyword is supposed to affect date formatting in Org output,
I must be missing a trick.

> So a two step method would be: (0) make sure that the document
> language is set correctly (similar to how the right babel language is
> selected in LaTeX), and (1) be able to change the format of the date.
>
> Or we could lose the date-stamp-feature and insert the date as
> plaintext.  This is probably simpler, but I don't know if this is the
> "correct" way.

>> Rasmus, will you be pursuing this?
>
> If you are thinking about fixing this, I won't stop you!  I dread
> ·xml.  This weekend sort of disappeared in (other kinds of) wasted
> efforts, so I haven't progressed on this.

Not anytime soon, I'm afraid; pressed for time.

Yours,
Christian

Re: [bug?, ox-odt] Format DATE

[Rasmus]

Christian Moe <mail@christianmoe.com> writes:

>>> Going by the documentation of org-odt-use-date-fields, the data styles
>>> "OrgDate1" and "OrgDate2" are supposed to be mapped from
>>> org-time-stamp-custom-formats, rather than
>>> org-export-date-timestamp-format. 
>>
>> Yeah, I saw that, but the description of
>> `org-time-stamp-custom-formats' looks a bit opaque.  I wondered if it
>> would affect the recognition of timestamps in buffer (since the
>> variable is not an org-export-· variable).  If it's truly *only*
>> affecting exports it should be renamed.
>
> No, judging by the manual entry, it was intended for customizing the
> appearance of timestamps in the buffer, which it does, see below. To
> accommodate people who think ISO time format is just too darned
> /sensible/...

O-o-okay.

> But it has the nice (and little-mentioned) side effect that you can use
> it to change the appearance of timestamps in exports, where
> non-geeky-looking everyday-language dates are often comme il faut. Works
> nicely in HTML, for instance, except that you still get geeky-looking
> brackets around the dates (may need a filter to remove those).

While I really want this functionality, I think that this way of using
it is a bug.  It should depend on a separate org-export-· variable. ..

> It's nice, for instance, if you have a document with a lot of dates in a
> European format and need to switch to an American format; you can do it
> by changing a setting.

Wait, so does this variable change how dates are interpreted or not?
I.e. can I "choose" whether <2010-01-10> is January 10th or October
first?  Or is an Org timestamp always in sensible ISO?

> And the ODT exporter builds on this to give date fields that can be
> further changed in LibreOffice.

Right.

>>> So this will apply to the output from the DATE keyword too.
>>>
>>> To make this happen, org-display-custom-times must be non-nil. 
>>> This affects not only the date in the heading from the DATE keyword,
>>> but also all other timestamps in the document.
>>>
>>> Having org-display-custom-times turned on all the time also puts
>>> overlays on the timestamps in your buffer, but if this annoys you you
>>> can bind it to be set during export only.
>>
>> OK.  I don't know this functionality.  It sounds less bad that what I
>> feared, but still the org-export-· variables should probably be
>> sufficient.
>>
>> Is `org-time-stamp-custom-formats' the recommend way of formatting
>> regular time stamps for export?
>
> I don't know about "recommended". It doesn't seem to be documented for
> export at all. And as for ODT, the code comments say the feature
> translating from custom time stamp formats to ODT date styles is
> "experimental". Seems to work OK, though.

I like the possibility, but I think export and buffer display should be
separated.

>>> But doing it this way still ignores
>>> org-export-date-timestamp-format, and any solution based on copying that
>>> variable into org-time-stamp-custom-formats makes unsafe assumptions about
>>> user preferences.
>>
>> Yes.
>>
>>> It seems to me that the export of the DATE keyword ought to honor a
>>> non-nil org-export-date-timestamp-format, whether or not the user is
>>> applying custom formatting to other timestamps. 
>>> But that would take some
>>> changes to several parts of ox-odt.el, I think.
>>
>> Yeah.  It's can be made even more complicated than that, since the
>> *document language* of the output also affects how dates are
>> formatted. . .
>
> In Org, or in LibreOffice once you set the language there? 

In LO some of the date formatting is a function of the document
language.  The document language (or maybe region language, I don't
really know...) is seen at the bottom.

Date has a gray background indicating it's special...  With sufficient
time and creativity you can get to a menu for formatting the date.  Some
of these formats (especially the "human-friendly" ones) will depend on
the language.

On the other hand, "Table of Contents" seems completely independent of
the document language. . .

> If the #+LANGUAGE keyword is supposed to affect date formatting in Org
> output, I must be missing a trick.

I think #+DATE might not be truly affected by #+LANGUAGE, after all, but
rather be affected of different system languages on my two home-PC and
work-PC (I'm unable to get this computer—which has English as a system
language—to export dates in other languages via
org-export-date-timestamp-format).  

This is probably a separate bug.

>> So a two step method would be: (0) make sure that the document
>> language is set correctly (similar to how the right babel language is
>> selected in LaTeX), and (1) be able to change the format of the date.
>>
>> Or we could lose the date-stamp-feature and insert the date as
>> plaintext.  This is probably simpler, but I don't know if this is the
>> "correct" way.

>>> Rasmus, will you be pursuing this?
>> If you are thinking about fixing this, I won't stop you!  I dread
>> ·xml.  This weekend sort of disappeared in (other kinds of) wasted
>> efforts, so I haven't progressed on this.
> Not anytime soon, I'm afraid; pressed for time.

That's fine.  I will try to look into this; hopefully soon.

—Rasmus

-- 
What will be next?