I'm currently in the process of migrating an sqlite_ecto2 project to this adapter and I noticed that this one does seem to store utc_datetime as iso strings with tz information (with trailing Z), while sqlite_ecto2 doesn't store an offset.
The comment here seems to suggest this is not yet set in stone:
|
# TODO: Should we be preserving the timezone? SQLite3 stores everything |
|
# shifted to UTC. sqlite_ecto2 used a custom field type "TEXT_DATETIME" |
|
# to preserve the original string inserted. But I don't know if that |
|
# is desirable or not. |
|
# |
|
# @warmwaffles 2021-02-28 |
I'd argue that the adapter doesn't want to push timezone knowledge into the db, just like the other ecto adapters do. Neither postgres nor mysql natively support a datetime column, which does retain timezone information. Even though timestamptz for postgres does convert between session timezone and the column value automatically, it also just stores UTC and not the input timezone – and ecto defaults to timestamp columns on postgres anyways. Additionally the :utc_datetime ecto type already makes sure the datetime is using UTC as timezone at runtime, so other timezones are not allowed for such columns in the first place.
Would you be open to adjusting the handling for :utc_datetime?
I'm currently in the process of migrating an sqlite_ecto2 project to this adapter and I noticed that this one does seem to store utc_datetime as iso strings with tz information (with trailing
Z), whilesqlite_ecto2doesn't store an offset.The comment here seems to suggest this is not yet set in stone:
ecto_sqlite3/lib/ecto/adapters/sqlite3/codec.ex
Lines 49 to 54 in 886bd6f
I'd argue that the adapter doesn't want to push timezone knowledge into the db, just like the other ecto adapters do. Neither postgres nor mysql natively support a datetime column, which does retain timezone information. Even though
timestamptzfor postgres does convert between session timezone and the column value automatically, it also just stores UTC and not the input timezone – and ecto defaults totimestampcolumns on postgres anyways. Additionally the:utc_datetimeecto type already makes sure the datetime is using UTC as timezone at runtime, so other timezones are not allowed for such columns in the first place.Would you be open to adjusting the handling for
:utc_datetime?