Comment 79 for bug 365065

Peter, not in principle, no. But it hasn't gotten any easier in practice. Well, maybe a little, because we've gotten rid of most of the separate Scheme date code and call the wrapped C functions for most date and time handling.

Managing stored data compatibility, whether in XML or SQL, will be a major part of any such change. GnuCash's sprawling and massively interdependent code base remains a major obstacle to fixing lots of basic design goofs and this one is no different. The subsystems don't hang together, more like they're tangled together.

You're pretty much stuck with me for a developer to work with, though others might chime in if you ask on gnucash-devel or IRC. Derek is still around and was involved the early design though he hasn't done any GnuCash coding for many years.

There are independent pieces that could be done first, for example reworking all of the standard interval code (Quarter, Month, Week) to use dates instead of times and storage backend changes to handle dates as well as times.

What were you planning to use for a date type? GLib's GDate? It's the only ready-made date implementation I know of that doesn't have a timezone problem, but we're trying to move away from GLib in GnuCash's core, preferring the C++ standard library. Unfortunately std::chrono is time-oriented and its date type is timezone-sensitive, as are boost::date_time and ICU's.