Thanks Simon! Don't worry about the type 'timestamp'. We know how SQLite works with types. We use timestamp because it is a good thing for documentation purpose. We actually store an integer or real in there according to our application rules.
For the short story we initially chose to always store Juliandays in our databases. But recently decided to change for a custom binary integer format which includes date, time, and bias from UTC. This is why we need to patch some older existing databases to use default (now()) instead of default (julianday()). Our now() returns the properly encoded integer. We also have overloads for date(), time() and datetime() to returning readable string values when some hand work has to be done on the command line. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia (from mobile device), integral.be/om > Le 23 mai 2016 ? 13:12, Simon Slavin <slavins at bigfraud.org> a ?crit : > > I notice only one thing, but you're at the time when it's easy to change it. > The 'type' you've picked for this column is 'timestamp'. SQLite has no such > type. I recommend you use one of INTEGER, REAL or TEXT depending on the > value that your 'now()' function returns. > > You won't have found a problem with it so far, but you may encounter one in > other parts of your program which set or obtain a value in that column.
