allow other date formats in journal via --input-date-format

[simonmichael]

Journal entry dates currently have to be in ISO-style YYYY/MM/DD format (or YYYY-MM-DD or YYYY.MM.DD or MM/DD or MM-DD or MM.DD). If we provided a Ledger-style --input-date-format option, folks could use that to write DD/MM/YYYY (and DD/MM) dates instead, without ambiguity. We already have this kind of support when parsing CSV files.

Localisation is good. On the downside this makes sharing journal files and snippets harder, and creates one more hurdle for newcomers to get right. I've had to remember and adjust --input-date-format multiple times when running ledger on some pasted sample. So is this really worth it ?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[gour]

So is this really worth it ?

I'd say if you would live in the country where dd.mm.yyyy. is used everywhere, the answer to above is quite simple. ;)

[simonmichael]

I grew up in such a country, but I've still always favoured the unambiguous sortable international-standard YYYY-MM-DD order for computing. But I note your plus vote. :)

[mcapodici]

I think it would be good to support showing different data formats in the UI, but the data stored on disk should be in one format only. I don't see the advantage in allowing different date formats in the Journal File when there is a command line UI to interact with the data and the data can be presented differently there. I agree with all of the disadvantages you mentioned though.

[gour]

I don't see the advantage in allowing different formats when there is a
command line UI to interact with the data.
Well, the point is one has to enter data as well, so why not having data in desired format?

[the-solipsist]

Journal entry dates currently have to be in ISO-style YYYY/MM/DD format

I think YYYY-MM-DD is "ISO style", rather than YYYY/MM/DD.

[Profpatsch]

I’m confused by the YYYY/MM/DD notation as well. I expected it to either

• use YYYY-MM-DD (ISO) dates everywhere
• use the user locale (LC_TIME, LC_ALL or LANG)

In all cases I think the plaintext files should only allow true ISO dates.

[the-solipsist]

This may be a separate issue, but as @hpdeifel notes in hpdeifel/hledger-iadd#14 (comment), the showTransaction function from hledger-lib produces dates in the format YYYY/MM/DD rather than YYYY-MM-DD (which is the ISO8601 format). This also affects how dates are displayed by hledger print, and in various reports. Should this potentially be changed as well?

[simonmichael]

A new issue should be opened, proposing and exploring how to make hledger tools and docs use the ISO date format by default (rather than the Y/M/D one I chose for historical reasons).

[varac]

Specially for hledger add I'd like either ISO8601 (YYYY-MM-DD) or it should honor the users LC_TIME locale var, which both don't apply.

[schoettl]

I think the journal file itself should have an unambigious spec and no localized versions for dates (except the few accepted formats @simonmichael mentioned in the first post).

date-format in CSV rules is perfect and neccessary for CSV import.

What I miss, is --output-date-format for hledger output (e.g. the register command's output). I think that would be useful to produce printed reports that are not awkward for "normal" clerks in Germany. Or did I miss something? Maybe I don't know hledger reporting tools yet...

@varac my hledger version 1.12.1 does support ISO format on hledger add.

[simonmichael]

It seems like there is some consensus that just ISO dates (or ISO plus a few punctuation variations, as we have now) is sufficient, and preferable, in journal files.

Then what about..

• the CLI ? Eg in the -b/-e/-p options, or the date:/date2: queries ? We allow more flexible smart dates there. I think allowing a different ordering of Y, M, D there could create a lot of hassle.

• dates entered in other UIs, eg in hledger-ui, hledger-web, hledger add ? Generally I think they should allow the same syntax as in the CLI. Maybe hledger-iadd allows other formats.

• timedot files ? Should allow the same date formats as journal files.

• timeclock files ? Consistency is good, but this is a pre-existing format. Does timeclock.el or Ledger allow ISO dates here ?

Output:

• from hledger (CLI) ? Should change to ISO format, Replace YYYY/MM/DD with YYYY-MM-DD in all documentation and in all printing commands #933 will handle this.

• from hledger-ui, hledger-web, and other tools ? Generally these should do what the hledger CLI does.

Docs:

• help and reference/tutorial/cookbook docs ? Also covered by Replace YYYY/MM/DD with YYYY-MM-DD in all documentation and in all printing commands #933.

[simonmichael]

What I miss, is --output-date-format for hledger output (e.g. the register command's output). I think that would be useful to produce printed reports that are not awkward for "normal" clerks in Germany.

@schoettl let's discuss that more on #933.

[ad-si]

I think that would be useful to produce printed reports that are not awkward for "normal" clerks in Germany. Or did I miss something? Maybe I don't know hledger reporting tools yet...

@schoettl Actually ISO8601 is the main date format in Germany (https://de.wikipedia.org/wiki/ISO_8601#Zusammenfassung), and DD.MM.YYYY is only a tolerated date format. So instead of supporting their bad habits, you should educate them about ISO8601 😉.

[simonmichael]

So I think we are rejecting the --input-date-format idea for now; our journal, timedot, and timeclock formats, and all UIs, already support ISO dates; so what's needed is to change docs, and the various tools' output; and this issue can be closed in favour of #933.