Timezone conversion about sqlpp11-connector-postgresql

[valsydalv]

Also, could you please help me with the code?
Why it was commented?

[matthijs]

I've looked into this, but I didn't write that part of the library. As far as I can see this can use some refactoring using the date library. Parsing is added a while ago and is done in the following way:

std::istringstream in {datetime_iso_string};
date::micro_seconds tp;
is >> date::parse("%FT%T%z", tp);

See here for the formatting options.

[valsydalv]

I think it can't be parsed with date::parse because I had a situation when the PostgreSQL returned an arbitrary number of digits in the fractional part.

I'll try to uncomment the lines to see if it help.

[matthijs]

According to this documentation, the resolution of datetime is 1 microsecond. Which datatype did you have that returned an arbitrary number of digits?

[valsydalv]

Timestamp.
e.g. instead this date 2018-03-27 06:46:03.40000 it returned this: 2018-03-27 06:46:03.4

[valsydalv]

Here is old CI status I've found: https://travis-ci.org/matthijs/sqlpp11-connector-postgresql/jobs/346028969

with the line
PostgreSQL debug: got date_time string: 2018-02-25 20:30:10.57572
and then
TIMESTAMP '2018-02-25 20:30:10.000000' != TIMESTAMP '2018-02-25 20:30:10.575720'

That's the reason why I've changed the ms parsing behavior in the last PR.

[valsydalv]

Also, am I correct that the library stores time in the UTC?

[matthijs]

The sqlpp library uses sqlpp::chrono::microsecond_point as time_point. And the microsecond_point is defined as follows:

using microsecond_point = std::chrono::time_point<std::chrono::system_clock, std::chrono::microseconds>;

According to the system_clock documentation it is stored as UTC. So yes, you are correct about storing the time in UTC.

[gagbo]

Probably fixed by #69 since this PR tries to stop ignoring timezones