On Friday, August 31, 2018 at 3:21:24 PM UTC-6, mrcyb...@gmail.com wrote: > > Hi Martin, > > I'd like to throw in my two cents as well... I'm learning Beancount anew > (coming over from Ledger) and so far I think it's great so far and I'm > digging deeper. Thank you for the well written documents that are helping > me learn so far. > > I'm not sure I understand the argument that ISO 8601 support would > introduce too much complexity. Isn't it just a matter of more granular > timing/ordering of transactions? >
Timezones Daylight savings Accounts in different timezones Booking specs referring to postings added from dates which have been timezone translated ... more I can't even fathom right now ... > Why would being able to optionally post the specific ISO 8601 time of > transactions introduce any change in Beancount functionality whatsoever? > It should behave exactly the same way. > It'll open a massive can of worms for very little gain. Lots of tickets, lots of unforeseen issues. Keeping things simple is hugely valuable. I'm surprised to see that Beancount does not support ISO 8601 (when it says > that it does in the documentation). > It supports the ISO8601 date format: YYYY-MM-DD > I fully expected to be able to use more precise date syntax such as > "2018-03-30T08:34:43+00:00", or even the syntax that Ledger supports. I > have assets in accounts that are in different timezones and the > corresponding institutions usually present their records in UTC. Since > Beancount does not support this it means I have to manually do timezone > calculations to figure out what day a given transaction took place... > You don't. Just use dates local to the accounts. When doing transfers, choose one of the dates. Doesn't matter that much. (Much more important would be to resolve the discrepancy between transaction dates and settlement/posting dates IMO.) > "Was it late in the night on Dec 31, or was it early morning Jan 1? Is it > in 2015 or 2016?" ... "Was it daylight savings or not?". Like I said, I'm > very surprised to see a lack of support for precise ordering of > transactions and do not really understand why that would be undesirable > especially in accounting where tax liabilities of great legal importance. I > fully expected to be able to provide a precise date that comes directly > from my records without manual modification, and that the software would > easily be able to know whether the transaction should be included in the > 2015 report vs the 2016 report based on the current local timezone (or > specific default timezone or UTC), or that the software would be able to do > the timestamp apples to apples calculations to know whether two > transactions are one year and one day apart for long term capital gains > calculations. The fact that I have to look out for manual calculations like > this seems not in line with the awesome automation ethos of the Beancount > project that you've articulated in the docs so far. > Let me ask you this: Are you currently ingesting all your accounts and having access to a global picture of your assets and expenses? If not, I'd be focused on that first. Get the system up and running, don't sweat the small detail. Start coarse. Accounting is an approximate art. The timezone is a second order detail; it would be nice to have, but it doesn't come for free -- it'll add a lot of complexity for very little gain (and a lot of work on my end, I'd rather work on investment-related features). As a compromise, one thing that could be done is to honor the value of an optional metadata field for sorting, making no assumptions on ordering in the rest of the code. You could stash the full date/time in there if you like. You could even write a plugin that translates timezones from your custom date/time field to override the actual date of the transactions. That might be a way to prototype the feature without causing breakage. You could even build this in as a plugin if you like. To put it succinctly I see these issues with no ISO 8601 support: > > - Grabbing a timestamp from a record can result in a tx being put in the > wrong day and even year. > Be careful around those dates, that's all. Sounds scary in theory; in practice, it won't matter. (You're not driving a trillion-dollar company with this, are you?) > - Manually altering every timestamp from disparate records in different > timezones does not seem reasonable. > Worrying about timezone on any transaction sounds like a huge waste of time to me. (There's a huge benefit to keeping things simple that people are too quick to write off.) > - Calculating long term capital gains (hold asset for one year and one > day) is not guaranteed to be accurate. > How often is this error bound to happen? Surely you review those manually? > - A Tx that happens on the year change boundary could be ambiguous as to > what year the taxes are owed. > - Txs can appear to be out of order. Tx1 appears to come after tx2 simply > because its record is from a different timezone. > That's true; the ordering thing can be a tad annoying sometimes, especially when cross referencing a journal produced by Beancount with a real-world statement. That's why in sorting the transactions I honor the line number so that same-day transactions appear in the same order as in your file. It's not perfect. > > I respectfully ask you to reconsider support for ISO 8601 precise time and > timezone. > I have a time problem... just not enough of it. There are at least 20 more useful major features I'd like to see go in Beancount before building that in. Best regards and thanks again for your great documentation, > > Mac > > > On Friday, August 31, 2018 at 4:30:52 PM UTC-6, mrcyb...@gmail.com wrote: >> >> Also, using date/time + tz opens up a rabbit hole of issues... when you >>> sort, what do you display? If you display the local dates, it won't look >>> like a list of sorted dates if you have txns from multple accounts. Do we >>> always convert all the input dates to UTC and then convert back out when >>> rendering the reports? That could get confusing if you compare with your >>> institution's statement (the dates won't match). e.g., when looking at a >>> journal listing, you'd have to make sure to render the dates based on the >>> timezone associated with that particular account. And what happens if you >>> look at a group of accounts? >>> >> >> An approach that makes sense to me would be the following: >> >> 1. Within the text file, all transactions simply have a true ISO 8601 >> timestamp. They match the timestamp as presented in original records from >> any institution so there is no confusion when reading over the actual text >> data or record data. >> >> 2. When Beancount runs, all transactions are first normalized to the >> desired timezone IN MEMORY. >> >> - Preferred timezone can be specified in an option to override >> DEFAULT to local timezone. >> - A date like "2018-10-10" should assume current local timezone as >> known by Python unless overridden. >> - A date like "2018-10-10T10:10:10" should assume current local >> timezone unless overridden. >> - A timestamp like "2018-01-01T05:10:10-00:00" should be converted >> into "2017-12-31T22:10:10-07:00" (for Mountain time for example) >> - Notice how this transaction will now be reported on for 2017, not >> 2018, as it should be for someone in Mountain time. >> >> 3. Now reports should be generated only after all transactions are >> normalized to timezone. >> > Here's what I could do for you, with relatively little investment in complexity: - Modify the parser to support parsing a full ISO8601 datetime, as you suggest. You get your input syntax. - When parsing, I ignore the time portion and just use the date as-is, but I attach the full parsed date/time object as metadata for you. - The rest of the codebase isn't modified to depend on time anywhere. - Then you build a plugin that will translate things as you see fit from the metadata field. Would that be a good first step? >From my perspective, I'm providing you with the syntax to build what you want, but I'm not committing to entering the time-consuming domain of dealing with timezone issues and tickets (not supported as a core feature). This is a bit similar to how Python3's grammar supports type annotations but doesn't do anything with them nor mandate how you use them otherwise (except they happen to provide a special "typing" module). Libraries like moment.js make it easy to manage timing. >> https://github.com/zachwill/moment <-- this a python library inspired by >> moment.js. >> > (How many times do we need to reinvent the wheel in the Python community?) The problem isn't the libraries - datetime already handles tz pretty well - the problem is with the inherent nature of the problem we're solving. On Fri, Aug 31, 2018 at 6:46 PM <mrcyber...@gmail.com> wrote: > Another place where I feel this limited timestamping doesn't work is in > price directives: > > 2014-07-09 price HOOL 579.18 USD > Assets/commodities change price, sometimes drastically, intraday. It > shouldn't be the prerogative of accounting software to limit that a user > cannot have two transactions in the same day that involve the same > asset/commodity. We need the ability to specify the exact time of an > asset/commodity intraday. > Beancount isn't designed for that use case. If you have >100's of transactions every day - say, you're doing active daytrading - you should probably use specialized software to do your P/L tracking and reporting, not Beancount. Thanks again for your consideration. > -- 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%2BhP5C%2BF6eyVf_enqMh6qSS-ic%3D2gPMdUA4t8AwDv4j6DmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
