>
> 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/e7761d8b-4721-4647-a46c-21aace772956%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
