MoritzR / fints2ledger

A tool for downloading transactions from FinTS banking APIs and sorting them into a ledger journal
MIT License
27 stars 8 forks source link

Support international standard time format ISO8601 #8

Open varac opened 4 years ago

varac commented 4 years ago

Please support creating dates in the international standard time format ISO8601 for both csv and journal files. I suggest using this as default (and make non-standard time formats optional), but at the end it's just important that it is supported.

i.e. now 2020/10/302020-10-30

MoritzR commented 3 years ago

Check out version 0.7.0, I added csv_date_format there (https://github.com/MoritzR/fints2ledger/commit/ede44ff2e7c691ecd28384bfc6f472139fe114e6) You can now specify the format on the command line --csv_date_format or in the config.yml at fints.csv_date_format.

The default will still use 2020/10/30, because that is also the default that hledger uses.

varac commented 3 years ago

awesome, thx !

varac commented 3 years ago

Works nicely. The only issue I encountered is that when the date format for existing transactions changes (sed -i -E "s|([0-9]{4})/([0-9]{2})/([0-9]{2})|\1-\2-\3|" transactions.csv), they will also get considered new in the journal matching process. But I guess that's how it is and I will do a slow migration to a the new date format.

varac commented 1 year ago

Just noticed that the new version defaults again back to dates with slashes, and the config option csv_date_format is not recognized anymore. Would it be much work to re-add the csv_date_format back ?

varac commented 1 year ago

The reason this is important for my use case is that fints2ledger now tried to re-add existing transactions, and I think it's because the I configured ledger.md5 to include date, and the old m5sums were calculated by with the ISO8601 format (or how does fints2ledger calculate the hash ?).

MoritzR commented 1 year ago

Yes you are absolutely correct on how the hash is calculated. If you need this mainly because it tries to re-add existing transaction, then I would suggest to use the --date flag instead to work around this, which only loads transaction past the set date. Set it to your last received transaction, or a few day before that. Then manually skip/replace the conflicting transactions that remain.

You will only need to do this once. Does this work for you?

varac commented 1 year ago

I'll give it a try!

varac commented 1 year ago

Works for me now, so I'd be fine with closing this.