Open dfelton opened 4 years ago
Value attempted to be inserted outcome of this: gmdate("Y-m-d H:i:s", (int) \substr((string) 1583635360570, 0, 10))
Not sure what's up yet. Prior record and all others for that matter worked fine.
Prior value: gmdate("Y-m-d H:i:s", (int) \substr((string) 1583627499792, 0, 10))
(yielding 2020-03-08 00:31:39.000
in the db)
column description:
+-----------------+---------------------+------+-----+----------------------+--------------------------------+
| Field | Type | Null | Key | Default | Extra |
+-----------------+---------------------+------+-----+----------------------+--------------------------------+
| trade_date | timestamp(3) | NO | | current_timestamp(3) | on update current_timestamp(3) |
+-----------------+---------------------+------+-----+----------------------+--------------------------------+
which by the way, what the hell is there an on update current_timestamp(3)
here? granted these records, once inserted, are never intended to be updated, ever. Still, this value shouldn't change on update.
Fucking timezones...
MariaDB validates DATETIME literals against the session's time zone. For example, if a specific time range never occurred in a specific time zone due to daylight savings time, then DATETIME values within that range would be invalid for that time zone.
Sure enough, March 8th was daylight savings time. "Spring Forward", and 12:31AM
never happened.
Fuck.
Update:
When the database server is set to +00:00
this is a non-issue, and probably should be what we should have the database set to anyways. Locally I've updated the time_zone
setting on the global settings of the machine, but a better solution here will be to revise the database adapter to always connect to the server with +00:00
regardless of what the server is set to (or, after connecting check the value and throw an exception if it is not what we expect).
Twice a year issue, and updating database server fixes it immediately. Will still want to revise application to force this configuration for every connection session.
Occurred while the
./bin/gemini logger:trade-history
command was chugging along...