Recording transaction time in addition to date

[Andrew Maffei]

Hi. For several years I've been interested in using Double Entry Bookkeeping to record source scientific data. I'm finally making good progress.

I've been working on a specification of conventions that extend ledger journal syntax so that it works for non-financial, scientific data. Amazingly (thank you John!!) I seem to be able to use ledger without any modifications to generate all sorts of useful reports re state, flow and other attributes of a system under study. There is still a lot of work to do however.

One thing I now need is the ability to record a transaction time down to fractions of a second.

My current thought is to clone a copy of ledger and try modifying it so that it can use the ISO 8601 date-time format (https://en.wikipedia.org/wiki/ISO_8601) which supports fractions of seconds in addition to several alternative syntaxes for date and time encoding.

I was wondering if anyone else had a suggestion on how to proceed on this before I dig in. I don't program much any more so I'm interested in any suggestions folks have on how to proceed. Thanks!

--Andrew Maffei

[John Wiegley]

>>>>> Andrew Maffei <drum...@mac.com> writes:

> Hi. For several years I've been interested in using Double Entry Bookkeeping
> to record source scientific data. I'm finally making good progress.

This is great news! I've actually been thinking about something similar since
the beginning of ledger's creation. I used to gather data from "du", for
example, to make queries about disk space usage; I also used it to track and
report on bandwidth utilization with my Internet provider.

I once made an attempt to make postings and transactions use Boost "ptime"
values instead of dates. However, the fact that so few users would've used
this functionality, and that doing so result in several complications, led me
to settle on days as the smallest unit of time. They are far simpler in many
ways (no local time issues, for example).

However, I've always wanted to have this option, since Ledger isn't really
about accounting, after all. :) It should be able to serve as a general
purpose calculator for transactional data of many kinds.

My estimate on doing this work correctly is: several man weeks. It will then
be many months before we discover all the implications of having done so.

John

[Andrew Maffei]

On Thursday, November 19, 2015 at 7:07:43 PM UTC-5, John Wiegley wrote:

>>>>> Andrew Maffei <drum...@mac.com> writes:

 Ledger isn't really about accounting, after all.

No, it's about many things. Pattern that get repeated at many levels but with different languages at each. Thanks for your encouraging words John!

Some of my most satisfying work has been to reverse engineer DEB a bit. I've come up with 12 or so extending elements that I think make it able to function in a non-financial world.

One new element is 4 new top level accounts (or rather account types) that have a more generic meaning than Income, Expense, Asset, and Liability. They are In, Out, Hold, and Commit. It takes a little time to explain, but one way to look at double entry bookkeeping is as a closed thermodynamic system.

When you say "several man weeks" to do the work, are you talking about implementing ISO 8601 format for ledger's date? I can take a crack at it, but if we're talking about "several man weeks" of your time, we're talking about a man-year or so of mine :-). However, if you could provide me with an outline of the work to be done I might have a friend I can tap on to help me out.

[John Wiegley]

>>>>> Andrew Maffei <drum...@mac.com> writes:

> When you say "several man weeks" to do the work, are you talking about
> implementing ISO 8601 format for ledger's date?

The yymmdd part of ISO8601 is trivial, just use --input-date-format and
--date-format. It's allowing nanosecond resolution times to be associated with
postings that's the trick. Right now the only entities that allow such
precision are pricing entries for computing exchanged values (-X).

John

[Andrew Maffei]

On Thursday, November 19, 2015 at 8:42:24 PM UTC-5, John Wiegley wrote:

It's allowing nanosecond resolution times to be associated with
postings that's the trick.

Truth be told, I won't need fractions of seconds for a long time - though I probably do need timezone support.  Does providing support for 1s level resolution make the job any easier? I'm guessing no.

[Andrew Maffei]

wondering if an intermediate step might be to modify ledger to support iso8601 typed metadata? I looked at boost and noticed there are the 2 functions: to_iso_string and from_iso_string that could be used to handle the following transaction-level metadata declaration.

; TimeStamp:: [20020131T235959]

If less time required, could you estimate a WAG( Wild A-- Guess) for level-of-effort for this John? Thx.

[John Wiegley]

>>>>> Andrew Maffei <drum...@mac.com> writes:

> wondering if an intermediate step might be to modify ledger to support
> iso8601 typed metadata? I looked at boost and noticed there are the 2
> functions: to_iso_string and from_iso_string that could be used to handle
> the following transaction-level metadata declaration.

> ; TimeStamp:: [20020131T235959]

This is certainly possible, however none Ledger's date-based logic will be
able to use this timestamp. It'll just truncate the extra information when it
goes to use it.

And you were right before, 1s vs. 1ns resolution represents no difference in
difficulty.

> If less time required, could you estimate a WAG( Wild A-- Guess) for
> level-of-effort for this John? Thx.

I don't think it will take you as far as you want to go.

John

[Andrew Maffei]

On Friday, November 20, 2015 at 10:56:32 AM UTC-5, John Wiegley wrote:

> ; TimeStamp:: [20020131T235959]

I don't think it will take you as far as you want to go.

I agree, in the long run it will not go as far as I need. Three things I was presently

thinking of using iso8601 typed metadata for were:

- to perform simple queries to select transactions (<.>) within a certain timeperiod

- to export the typed metadata values as csv in alternative date-time formats

- to merge and then time-sort transactions

Interestingly, as I look at the date-time syntax above I realize that an ASCII sort

and greater-than, less-than ops might do the trick, hmmmmm.