Fixed date/time handling

[agalanin]

SQLite's internal date and time functions use UTC time zone. So we need to adjust date/time formatting and scanning in library to always use UTC.

[gitblit]

It seems like this moves the driver away from the JDBC spec by ignoring the user supplied Calendar/Timezone information.

[agalanin]

Unfortunately there are no sqlite datatype like 'timestamp with timezone' in postgresql, so timezone information is lost during saving in sqlite database.

[gitblit]

I like the idea of wrangling the date/time type. Looks like the driver is storing text formatted dates using the local timezone. That was probably a mistake. I'm concerned about backwards compatibility with this change. Need more eyeballs on this review.

[TuomasKiviaho]

I'm getting +2 hours with Europe/Helsinki time zone when using date_class=text

[gitblit]

@TuomasKiviaho A quick search tells me Helsinki is GMT+3 right now with DST. Are you saying your dates are actually +5 compared to GMT (and therefore +2 compared to what you expected)? Or are you saying they are GMT+2 ? Or some other combination? Fun with timezones...

[TuomasKiviaho]

Hi, 14:01 saved as string became 16:01 when I applied the UTC timezone fix. I didn't investigate it any further than that. Works OK with machines set in UTC timezone. Below is the snipped that I'm using.

 case SQLITE_TEXT:
                try {
                    return new Timestamp(stmt.conn.timestampFormat.parse(db.column_text(stmt.pointer, markCol(col))).getTime());
                }
                catch (Exception e) {
                    SQLException error = new SQLException("Error parsing time stamp");
                    error.initCause(e);

                    throw error;
                }

Fun with timezones...

Using org.threeten could be slightly less fun, but that's another story.

[gitblit]

Hi, 14:01 saved as string became 16:01 when I applied the UTC timezone fix.

Yeah, problems along those lines are what I was expecting. Hmmm...

[agalanin]

Any news?