wish: hledger should support transactions with timestamps, following ISO8601

[tphyahoo]

Currently hledger transactions look like

2009/1/1
assets:cow_account COW1 ; one cow at 100USD
equity:cow_account -COW1

The proposal is to allow transactions that have a precise timestamp such as

2007-04-05T14:30Z
assets:cow_account COW1 ; one cow at 100USD
equity:cow_account -COW1

, where the Z indicates UTC time zone.

If no time zone is specified, the time zone could be inferred using rules in a config file, or directive.

[simonmichael]

It seems a nice option, though possibly at the cost of making it harder
to provide clear parse errors. Would ledger also parse it ?

For the moment, you could also store it as a tag (metadata), like

2007-04-05                     ; time:14:30Z
  assets:cow_account   1 COW
  equity:cow_account

[xiaoruoruo]

Nice option. Maybe make a option to output ledger-compatible file by only outputting the date part?

[simonmichael]

Do we have some use cases ?

Needs discussion/developers, closing for now.

[adius]

Modern payment providers like PayPal, Bitcoin, etc. provide millisecond precision for their transactions. It should be possible to reflect that in a journal. This is an aboslute "must have" feature. I was really surprised that it's not already integrated!

[simonmichael]

Hi, why is it "must have" ?

When someone truly needs it, I expect we'll have it. For now, you can model this with a transaction tag.

[ony]

I miss that feature only for merging multiple journals. Example: I have some balance assertions/assignments from bank account in one journal and automatic export of expenses on my shop account in other. Without precise time in transactions they are not intermixed for a single day.
Work around: keep only one journal and periodically merge in transactions from generated ones.

If someone will start implementing it, I would like that person to consider treatment of transactions that are within the same day but with mix of those that have time and that don't.
I can imagine that sequence of transactions without time specification will be assigned to a time range that spans between closest pair of transactions with time specification but don't cross day boundary. During merge of transactions from a different sources that belong to overlapping ranges we can follow current approach (order of read) effectively preserving current behaviour.

Imagine file 1, A, 4, 3, B, 7, 6, C, 8. We have ranges like: A:(1;4), B:(3;7), C:(6;8). I.e. there will be multiple ways to order transactions. Though we still can come up with some decision like to prefer placing transactions with time specification earlier while satisfying time range for those that have no time specification. I.e. 1, 3, A, 4, 6, B, 7, C, 8.

[ellis]

@simonmichael I would love this for bookkeeping as an Amazon seller because Amazon pays out settlements over time periods that begin and end sometime in the middle of the day. We want to validate the settlement reports, and ISO8601 timestamps would certainly be the easiest way to handle such cases. Adding a time tag seems like quite a hack, but if I use that, can you say what the query format should be for select the entries between two timestamps?

[simonmichael]

This sounds like a good use case, but can you explain it in more detail ? Why must you have a timestamp ?

[ellis]

Here's some context: One recent settlement covered transactions in Germany between 2017-11-08 21:22:04 UTC and 2017-11-22 21:23:20 UTC. Other countries have different settlement periods, but the periods are usually 14 days in duration.

I need to match all transactions to their invoices, and all bank transfers to the 14-day settlements. We sometimes find discrepancies in the settlement values, so we need to validate them all. Right now, I'm running these calculations in R (https://www.r-project.org/). However, it would be much nicer to just query the ledger for the transactions between two time-stamps; then we could compare the ledger subtotals with reality. Does that make sense?

Any update on this?

[simonmichael]

@ellis: yes it makes sense, thanks. Here's a mockup to explore how it could be hacked with current features:

; #117 how to match between 2017-11-08 21:22:04 UTC and 2017-11-22 21:23:20 UTC ?

2017-11-08 ; time:21:22:00
  (a)        1

2017-11-08 ; time:21:22:04
  (a)        2

2017-11-22 ; time:21:23:20
  (a)        3

2017-11-22 ; time:21:23:21
  (a)        4

$ hledger print date:2017-11-08..2017-11-23
2017-11-08  ; time:21:22:00
    (a)               1

2017-11-08  ; time:21:22:04
    (a)               2

2017-11-22  ; time:21:23:20
    (a)               3

2017-11-22  ; time:21:23:21
    (a)               4

# and filter out the outside-time-bounds transactions by hand

...is what I've come up with so far. I suspect you could accomplish the precise match through clever tag:time=REGEXP queries, but it looks too hard even for a PTA fanatic. It would help a lot if tag: could match on values greater or less than something, as amt: queries can. Eg this could work, assuming well formed data:

$ hledger print date:2017-11-08..2017-11-23 tag:'time>=21:22:04' tag:'time<=21:23:20'

[alerque]

I've recently run into some trouble de-duplicating transaction lists because the only uniquely identifying information would have been timestamps with more granular precision that "day". I've also run into considerable confusion generating sensible reports on cryptocurrency transactions where the rate changes and transaction flow only really makes sense on a much tighter timeline than "day".

[simonmichael]

@alerque where do you hit trouble with current hledger exactly.. is it in filtering by time, as in the example above ? Would the proposed quick solution (tag value comparison queries) solve it ?