change in date format in 2.7

[Alen Siljak]

   I'm more than happy to do that but Python bindings don't even seem to
   be available for Windows at this stage. Which is a deal breaker for me,
   for example.
   --
   Sent from my Android phone with GMX Mail.

   On 21/12/17, 03:14 John Ralls <jralls at ceridwen.us> wrote:

     Alen,

   Oh yeah, SQLite3. That doesn’t have a date type so the backend stores a
   formatted string. We use ISO formatted date output for a lot of other
   things and I didn’t see a good reason to write a special output
   function just for the SQLite3 backend when I rewrote the SQL backend in
   C++.

   We consider the data file formats and SQL schemas to be private
   implementation details.  If we make a change that breaks Piecash, too
   bad. I told Sébastien that repeatedly and at length three years ago
   when he embarked on the project.

   The desired state at this time is that you work on improving the
   GnuCash python bindings and use those.

   Regards,

   John Ralls

   \On Dec 20, 2017, at 12:37 PM, Alen Siljak <[1]alen.siljak at gmx.com>
   wrote:

     John,
     With 2.7.2, the datetime field in sqlite3 database has increased to
   19
     chars, as Sebastien reported. The new format is yyyy-mm-dd HH:MM:ss
     instead of yyyymmddHHMMss.
     It appears that the application can read both formats in a book and
     that part is not a problem.
     However, we are trying to set up the piecash library to utilize
   either
     one or both formats (if possible with SQLAlchemy data layer to use
   both
     patterns for conversion to Python datetime type).
     Now that you say this was not intentional, I'd like to know what is
   the
     desired state at this time. I have updated almost all my date columns
     to the new format so that I could continue using gnucash_portfolio
   set
     of functions and reports, which use the piecash data model underneath
     and still read my book file after upgrade to 2.7.2.
     Any clarifications are welcome! :)
     Cheers,
     Alen

     On Dec 20, 2017, at 4:38 AM, Sébastien de Menten <sdementen
     at [2]gmail.com> wro

   te:

     Hello,
     In books created in gnucash 2.7, the size of the field for date has
     been
     increased from 14 to 19 characters to move from a custom format to
     an ISO
     format if I understand properly.
     This is a backward incompatible change, correct ?
     ie GC 2.7 will read previous books and "migrate" them to the new
     format but
     then the books will not be readable by GC < 2.7.

     Uh, what file format do you mean? The only intentional change was to
     MySQL wher

   e we replaced TIMESTAMP >with DATETIME, but that appeared during
   testing to be t
   ransparent.

     But otherwise, no, it’s not necessarily incompatible as long as the
     date parser

   can understand the input >it will work either way. Did you test and
   find that s
   ome 2.6.x was unable to read a 2.7.2 file or database?

     Regards,
     John Ralls

   _______________________________________________
   gnucash-devel mailing list
   [3]gnucash-devel at gnucash.org
   [4]https://lists.gnucash.org/mailman/listinfo/gnucash-devel

References

   1. mailto:alen.siljak at gmx.com
   2. http://gmail.com/
   3. mailto:gnucash-devel at gnucash.org
   4. https://lists.gnucash.org/mailman/listinfo/gnucash-devel