On Thu, Mar 29, 2018 at 11:37 PM, <byvo...@gmail.com> wrote: > Hi Ratish & Martin, > > Is there any time support implemented? >
No, I chose not to add that on purpose, in the name of simplicity. That would also open the door to supporting day trading, and that would bring a host of other complexities that IMO are out of scope. For that you'd want something more specialized. What about time zone support? This is very useful for frequent > international travelers. If I fly eastbound trans-pacific flight, for > example, Tokyo to San Francisco, the date will be the same but the local > time will backtrack. > That would be a very rare occurrence not worth optimizing for, and besides, the date you should record is the date of the place where the transaction occurred (for the corresponding institution). It's not designed to take into account time, and some small amount of fuzziness is considered okay. For instance, at the moment there's no support for distinct transaction vs. posted dates, we just fuzz the date in those few places where things don't square up, e.g. they straddle a balance assertion or something. (That, will get handled correctly eventually (see the discussion here https://docs.google.com/document/d/1x0qqWGRHi02ef-FtUW172SHkdJ8quOZD-Xli7r4Nl_k/), as there is a certain elegance to being able to replicate a precise copy of an institution's transaction record, I definitely want that eventually.) My proposal is to make the date fully ISO 8601, like 2018-03-30T08:34:43+09:00, > instead of just 2018-03-30. > > What do you think? > This would introduce unnecessary complexity for very low marginal benefits. It also makes the software unfairly seem like it's designed to solve problems it clearly has been thought out for. Furthermore, right now the ordering assumptions are loose - no guarantees on ordering of transactions occurring on the same day, all balance assertions appear at the front of each day -- this would introduce a change in these assumptions, and a fair amount of code depends on it. In short: not worth it. Thanks, > Carbo > > On Sunday, October 2, 2016 at 12:14:35 PM UTC+9, Martin Blais wrote: >> >> +beancount >> >> On Sat, Oct 1, 2016 at 3:24 PM, Martin Blais <bl...@furius.ca> wrote: >> >> On Fri, Sep 30, 2016 at 11:56 AM, Ratish Punnoose <rat...@gmail.com> >>> wrote: >>> >>>> Hi Martin, >>>> I am doing the accounting for a school festival and was scoping out >>>> your project, beancount. It looks very cool. Thanks for developing it. >>>> >>> >>> Thanks! >>> >>> >>> In your comparison document (with ledger + others), you mention that >>>> beancount only has a resolution of a single day. Do you have any future >>>> plans to provide time resolution? >>>> >>> >>> No. >>> >>> A while back I decided it was out of scope and this would keep the code >>> simpler. So far it seems like it was a good decision. If you need something >>> like that - e.g. for intra-day trading with 100+ trades, or for managing a >>> large sales operation - I figure more specialized software is in order >>> anyhow. >>> >>> >>> In my use case, a festival spans multiple days but it is extremely >>>> useful for us to get reports hour-by-hour for many booths. We currently do >>>> this with spreadsheets. This is needed for us to make a lot of decisions, >>>> checking trends, comparing historical performance, and correlating with >>>> other events that are happening. I can also imagine other use cases, >>>> where accounting reports are done per multi-hour shifts. >>>> It would be quite useful for beancount to provide at least a one-hour >>>> resolution. >>>> >>> >>>> If you don't have plans to support this, could you provide some advice >>>> on what modifications would have to be made to support this. For a start, >>>> we wouldn't need to report across timezones. Does that make it simpler? >>>> If it is not a huge endeavor, I would like to see if I can contribute on >>>> this front. >>>> >>> >>> Hmm, let's see. I think you could actually do this with the current >>> system with pretty minimal changes. >>> >>> First, let me explain how sorting works, which is the key subject here >>> when we think about time. One important invariant Beancount ensures is that >>> the order of your input is not relevant. All directives - of all types, >>> Transaction and others, like Balance - are sorted in data order, and then >>> by type. If on the same date, Open directives always come first, then >>> Balance directives (thus they apply at the beginning of a day), then the >>> Transactions and everything else, and finally, Close directives. The code >>> that expresses this rule is here: >>> https://bitbucket.org/blais/beancount/src/5d1390225e9a27590d >>> dace440ebb34b723f731c8/src/python/beancount/core/data.py? >>> at=default&fileviewer=file-view-default#data.py-482 >>> >>> Note also that the line number is included in the sort-key, but none of >>> the calculations anywhere do anything special within a day, so it doesn't >>> matter. It's only there to ensure a "stable" sorting order (meaning every >>> time you sort you obtain the exact same result), which helps when writing >>> tests. >>> >>> Adding storage is trivial; ideally one would include that in the >>> grammar, but that would be a pretty invasive change. I think you could >>> start by adding some metadata field, e.g. "time", and pulling it in the >>> sort-key, it it's present, e.g. >>> >>> 2016-10-01 * "Sale #1" >>> time: "04:05" >>> ... >>> >>> >>> and monkey-patching data.entry_sortkey() like this: >>> >>> def entry_sortkey(entry): >>> return (entry.date, SORT_ORDER.get(type(entry), entry.meta.get('time', >>> None), entry.meta['lineno']) >>> >>> Note a few things: >>> >>> - I'm placing the sort order in front of the time here; I'm assuming you >>> don't need Balance check within the day. If you do, you could make those >>> respect time and change the field order. I'm not sure if everything else >>> keeps working - you'd have to try it out - but I suspect it will. >>> >>> - I'm using .get() instead of [] on "meta" so that you may leave the >>> field as absent. This means that for transactions with no time, they'll >>> appear before the other entries with time. You could provide a default >>> value for time of your own choice if you'd want to do differently. >>> >>> - The meta-data value in my example is a string. You might want to >>> implement a plugin that verifies that the input syntax is correct if those >>> are manually entered, e.g. "\d\d:\d\d". >>> >>> Based on this, you could then use the SQL shell to extract the time and >>> do run some aggregations. I think you'd want to add a few custom functions >>> to the bean-query environment, in here: >>> https://bitbucket.org/blais/beancount/src/5d1390225e9a27590d >>> dace440ebb34b723f731c8/src/python/beancount/query/query_ >>> env.py?at=default&fileviewer=file-view-default >>> >>> I'm thinking of some functions to get the time metadata (META() can do >>> that, but you might want to add a virtual "time" column which would look >>> nicer), and some functions to round your time strings to e.g. hours. >>> >>> >>> So essentially, I just fleshed out how to add time to Beancount. If >>> - doing this doesn't add significant processing time, >>> - adding this time metadata is optional >>> - we wrote a lot of unit tests, >>> I'd consider adding this to the default branch. >>> >>> As always, the problem with these things is all the unintended >>> consequences down the road, and the devil is always in the details. >>> >>> I hope this helps, please do let us know if you give this a shot. >>> >>> >>> >>> >>> >>>> >>>> Thanks >>>> Ratish Punnoose >>>> >>>> >>>> >>>> >>>> >>> >> -- > You received this message because you are subscribed to the Google Groups > "Beancount" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beancount+unsubscr...@googlegroups.com. > To post to this group, send email to beancount@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beancount/04d4d242-81d5-4926-a06f-e3b4ec9ba83a%40googlegroups.com > <https://groups.google.com/d/msgid/beancount/04d4d242-81d5-4926-a06f-e3b4ec9ba83a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to beancount+unsubscr...@googlegroups.com. To post to this group, send email to beancount@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhNfEsB6PPubWXzrAh7gx%3D%2Bh%3DAYn3VgDdoDJpG2Mf1nyCQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
