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. Thanks again for your consideration. 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. > > > Libraries like moment.js make it easy to manage timing. > https://github.com/zachwill/moment <-- this a python library inspired by > moment.js. > > > > > 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? 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. >> >> I'm surprised to see that Beancount does not support ISO 8601 (when it >> says that it does in the documentation). 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... "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. >> >> 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. >> - Manually altering every timestamp from disparate records in different >> timezones does not seem reasonable. >> - Calculating long term capital gains (hold asset for one year and one >> day) is not guaranteed to be accurate. >> - 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. >> >> I respectfully ask you to reconsider support for ISO 8601 precise time >> and timezone. >> >> Best regards and thanks again for your great documentation, >> >> Mac >> >> On Saturday, March 31, 2018 at 11:19:08 AM UTC-6, Martin Blais wrote: >>> >>> On Sat, Mar 31, 2018 at 11:38 AM, Justus Pendleton <just...@gmail.com> >>> wrote: >>> >>>> On Saturday, March 31, 2018 at 10:07:31 AM UTC+7, Martin Blais wrote: >>>>> >>>>> 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. >>>>> >>>> >>>> First, I agree that it isn't worth optimising for and some small amount >>>> of fuzziness is considered okay. >>>> >>>> That said, I don't think it is quiet as rare as you suggest. Anyone who >>>> has banks in a different timezone (e.g. Europeans who have moved to >>>> America >>>> or vice versa, among the many kinds of other expats) will always see >>>> issues >>>> around this. As an example from my life: >>>> >>>> I live in GMT+10 but have banking in GMT-8. This means any time I do a >>>> transaction on (what to me) is a Friday, my bank records it on what is (to >>>> them) Thursday. I have hundreds of transactions like that in beancount at >>>> this point. >>>> >>>> In practice, though, this is rarely an issue. As you said, things like >>>> balance statements are one of the few times where it ever comes up. There >>>> are a few times where things happen on a month boundary -- I make a >>>> payment >>>> on (to me) April 1 but my bank treats it as March 31 -- and for >>>> budgeting/tracking reasons I would prefer it be part of April. But I'm >>>> pretty sure I don't want the overhead of needing to attach a timezone to >>>> hundreds of entries just to handle those one or two times an edge case >>>> creeps up. >>>> >>> >>> Interesting. When we do have separate transaction and posting/settlement >>> dates, this will become an issue indeed, as we will raise our expectations >>> on what's possible and not accept so easily the need to fuzz. >>> >>> >>> You'd need to do something like have a default timezone per account but >>>> allow overrides and....this is how scope creep happens. >>>> >>> >>> Another possibility is to write a plugin to conditionally shifts the >>> dates of particular accounts. I'm not sure if that would work in all cases, >>> but if you only have a few remote accounts, maybe that's enough. It seems >>> to me the transfer accounts that will be filled in automatically from the >>> settlement proposal will handle your use case nicely. >>> >>> 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? >>> >>> >>> >>> >>> >>>> -- >>>> 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+...@googlegroups.com. >>>> To post to this group, send email to bean...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/beancount/c6e95a02-44ca-4b3e-9c2d-662f0c8afbf8%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/beancount/c6e95a02-44ca-4b3e-9c2d-662f0c8afbf8%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/ba1ec377-2d41-4bfa-a41d-185820c7e987%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
