Re: beancount with day+time

1,229 views
Skip to first unread message

Martin Blais

unread,
Oct 1, 2016, 11:14:35 PM10/1/16
to Beancount, Ratish Punnoose
+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:

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:

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

  




Message has been deleted

Martin Blais

unread,
Mar 30, 2018, 11:07:31 PM3/30/18
to Beancount
On Thu, Mar 29, 2018 at 11:37 PM, <byv...@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

--
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+unsubscribe@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/04d4d242-81d5-4926-a06f-e3b4ec9ba83a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Justus Pendleton

unread,
Mar 31, 2018, 11:38:02 AM3/31/18
to Beancount
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.

You'd need to do something like have a default timezone per account but allow overrides and....this is how scope creep happens.

Martin Blais

unread,
Mar 31, 2018, 1:19:08 PM3/31/18
to Beancount
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+unsubscribe@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.

mrcyb...@gmail.com

unread,
Aug 31, 2018, 5:21:24 PM8/31/18
to Beancount
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
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.

mrcyb...@gmail.com

unread,
Aug 31, 2018, 6:30:52 PM8/31/18
to Beancount
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.

mrcyb...@gmail.com

unread,
Aug 31, 2018, 6:46:24 PM8/31/18
to Beancount
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.

Martin Blais

unread,
Aug 31, 2018, 9:29:22 PM8/31/18
to Beancount
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 <mrcyb...@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.

MacGregor

unread,
Sep 1, 2018, 4:37:25 PM9/1/18
to bean...@googlegroups.com
Thanks for the replies.

Basically I have two needs that I'm trying to understand if Beancount can handle.  I've read through the docs and cookbook but it looks like it might not be able to handle it:

1.  Trading currencies while tracking lot pricing in dollars (I'm not a daytrader doing 100s of txs per day, but in principle I don't feel that should matter).  For example trade JPY for CAD while the cost basis of lot JPY is tracked in USD and the capital gains are calculated in USD.
2.  If there is a day where the above JPY is sold in two batches where the JPY/CAD price has changed, can Beancount handle that?

Thanks

--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/zZiFBPU1V8Y/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAK21%2BhP5C%2BF6eyVf_enqMh6qSS-ic%3D2gPMdUA4t8AwDv4j6DmA%40mail.gmail.com.

Justus Pendleton

unread,
Sep 1, 2018, 9:18:44 PM9/1/18
to Beancount
On Saturday, September 1, 2018 at 5:46:24 AM UTC+7, MacGregor wrote:
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.

This works perfectly fine in beancount. (I've done it.) Have you tried it?

price statements have nothing to do with making transactions; you specify the price in a transaction. It is entirely possible to effectively use beancount and never make a price statement. They are primarily (only?) useful for reporting. It makes little sense to me to extend the parser to support time unless bean-query also supports time.

Martin Blais

unread,
Sep 1, 2018, 10:09:15 PM9/1/18
to Beancount
On Sat, Sep 1, 2018 at 4:37 PM MacGregor <mrcyb...@gmail.com> wrote:
Thanks for the replies.

Basically I have two needs that I'm trying to understand if Beancount can handle.  I've read through the docs and cookbook but it looks like it might not be able to handle it:

1.  Trading currencies while tracking lot pricing in dollars (I'm not a daytrader doing 100s of txs per day, but in principle I don't feel that should matter).

Of course it does. If, say, the maximum number of trades you're envisioning is not unreasonable, double it. It that's still reasonable, double it. Go on, until it's not. Surely there is /some/ number at which point it makes more sense to start using a system with a different set of feature priorities. Beancount is designed in terms of a regular person's personal finances inputting all this data themselves. Maybe /maybe/ its model extends to a high frequency trader-- maybe not. Maybe it can track the assets of a billionaire-- maybe not. I suspect in those extreme cases, they may be better served by a different kind of implementation. I can't guarantee it.

 
  For example trade JPY for CAD while the cost basis of lot JPY is tracked in USD and the capital gains are calculated in USD.

No problem.
Debit from an account in CAD, converting to USD
On the other leg, add your position of JPY with cost basis in USD.

 
2.  If there is a day where the above JPY is sold in two batches where the JPY/CAD price has changed, can Beancount handle that?

No reason why not, it should work.

As for FOREX trading, as long as you think of assets as currency pairs, it should work as for stocks.
There is a quirk that can materialize in FX trading, however, where you aggregate all your positions in terms of relative currency exposures, and Beancount hasn't received special treatment for dealing with that. (I used to trade currencies on institutional platforms (e.g. EBS, Reuters, Hotspot, etc.), so I'm reasonably familiar with the issues involved.) I'm not sure how gracefully it can deal with this, but I think the trading accounts method should provide a general enough framework to deal with this. 

 
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.

lepre...@gmail.com

unread,
Sep 8, 2018, 4:32:45 PM9/8/18
to Beancount
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).

I'd say that sounds like a workable plan. We get consistent datetime input, and access, at minimal maintenance cost.

Martin Blais

unread,
Sep 9, 2018, 1:24:52 PM9/9/18
to Beancount

--
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/d6a65c2c-3ee2-4d69-b3e2-b5c94be62645%40googlegroups.com.

Tony Xiao

unread,
Sep 22, 2020, 8:25:50 PM9/22/20
to Beancount
Was the parser to support ISO8601 ever implemented btw? When I click on the issue it shows a link not found error. 

Martin Blais

unread,
Sep 22, 2020, 11:18:03 PM9/22/20
to Beancount
Repo was moved to github.
ISO8601 / UTF8 will be part of v3 (prototyped, using RE/flex, works well).


To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/d83aad63-140a-434c-8bec-8a81e3ca2304n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages