> > 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. -- 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/d6a65c2c-3ee2-4d69-b3e2-b5c94be62645%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.