+2018-04-08 Russ Tyndall <russ@acceleration.net>
+ * sql/db-interface, expressions, fdml, generic-postgres
+ db-mysql/mysql-sql.lisp db-postgresql-socket3/sql.lisp
+
+ - I created a new protocol function (database-escape-backslashes
+ database)
+ - I changed the the generic mysql and postgres databases
+ to return T
+ - I made the postgresql-socket3 backend check for
+ standards_conforming_string which is exposed in the underlying
+ cl-postgres connection
+ - It seems likely that postgresql-socket3 could always return NIL, as
+ cl-postgres would probably handle this escaping anyway
+
+ This replaced some special case code in (database-output-sql (string
+ database))
+
+
+2018-02-04 Russ Tyndall <russ@acceleration.net>
+ * sql/generic-postgres.lisp:
+ Wall times default to being timestamptz in postgresql now.
+ There was a TODO questioning why it was storing zoneless by
+ default - it was because of the bugs about tracking UTC
+ vs zoneless
+
+
+2018-02-03 Russ Tyndall <russ@acceleration.net>
+ * sql/time.lisp, tests/time.lisp:
+ Better distinguishing between zoneless timestamps and UTC times,
+ particularly as relates to postgresql-socket(3) backends. Without
+ this change, timestamptzs are read as localtimes and saved as
+ localtimes, when they should be read and printed as UTC times,
+ this bug will lead to dates changing every save as they are being
+ reconverted to UTC again.
+
+ We followed a minimal approach (following postgresql' lead), we
+ simply add a is-utc? boolean. Before this, zoned times were
+ converted to UTC, but since we never tracked that it was a UTC
+ time vs a zoneless time, there was conflation between the two. In
+ order to preserver comparability between dates and times that are
+ local vs UTC. I wrote a `time-to-utc` utilizing decode-time's
+ implementation dependent timezone defaulting.
+ (I verified the math by comparing results to the local-time
+ library from quicklisp).
+
+ Ultimately, adoption of a third party datetime library is my
+ strong preference (eg: local-time). While this project has, as a
+ whole refrained from outside requirements, I think that we should
+ consider moving to local-time as our date / time format, or
+ providing that as an option, both to support a semi standardized
+ eco system, and also to have a more robust timestamp implementation.
+
+
2016-01-26 Kevin Rosenberg <kevin@rosenberg.net>
* Version 6.7.0 release
* sql/utils.lisp: Apply patch from Martin Simmons for