Thanks for the clarification!
On Dec 21, 2017 20:18, "John Ralls" wrote:
That's our general forwards-compatibility guarantee: The last version of
2.6.x is the only version guaranteed to be able to read a 2.8.x
database/file. In this case (but not in several others) users
That's our general forwards-compatibility guarantee: The last version of 2.6.x
is the only version guaranteed to be able to read a 2.8.x database/file. In
this case (but not in several others) users will be able to save their
databases in another format and read it with earlier versions. I'll
> On Dec 21, 2017, at 1:27 AM, Alen Siljak wrote:
>
> To get back to Sebastien's question: this does seem like a breaking change at
> this stage. Going back to 2.6.19 with the database where a few transactions
> have been entered in 2.7.2 shows the dates as 1970-01-01.
To get back to Sebastien's question: this does seem like a breaking
change at this stage. Going back to 2.6.19 with the database where a
few transactions have been entered in 2.7.2 shows the dates as
1970-01-01.
>Alen,
>
>Oh yeah, SQLite3. That doesn’t have a date type so the
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 wrote:
Alen,
Oh
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
John,
With 2.7.2, the datetime field in sqlite3 database has increased to 19
chars, as Sebastien reported. The new format is -mm-dd HH:MM:ss
instead of mmddHHMMss.
It appears that the application can read both formats in a book and
that part is not a problem.
> On Dec 20, 2017, at 4:38 AM, Sébastien de Menten wrote:
>
> 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