support microseconds resolution for created_at/updated_at/deleted_at

[wesleywu]

We often need microseconds resolution for timestamp/datetime columns, especially when we sort records by timestamp column and do some batch processing.

The current implementation in GF uses String() representation of gtime/time for insert/update operations, thus truncating the time precision to second.

[codecov-commenter]

Codecov Report

Patch coverage: 100.00% and project coverage change: -0.02 ⚠️

Comparison is base (1cd1449) 78.62% compared to head (19d0c19) 78.61%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2512      +/-   ##
==========================================
- Coverage   78.62%   78.61%   -0.02%     
==========================================
  Files         630      629       -1     
  Lines       51318    51158     -160     
==========================================
- Hits        40349    40217     -132     
+ Misses       8984     8963      -21     
+ Partials     1985     1978       -7     

Flag	Coverage Δ
go-1.15-386	?
go-1.15-amd64	78.63% <100.00%> (-0.02%)	⬇️
go-1.16-386	?
go-1.16-amd64	?
go-1.17-386	?
go-1.17-amd64	?
go-1.18-386	78.58% <100.00%> (-0.01%)	⬇️
go-1.18-amd64	78.59% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
contrib/drivers/dm/dm.go	73.25% <100.00%> (+0.12%)	⬆️
database/gdb/gdb_model_delete.go	100.00% <100.00%> (ø)
database/gdb/gdb_model_insert.go	64.35% <100.00%> (ø)
database/gdb/gdb_model_update.go	68.47% <100.00%> (+0.34%)	⬆️

... and 15 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[wesleywu]

MySQL 5.7 does not recoginze +07:00 in timestamp string, while MySQL 8.0/PostgreSQL/MSSQL/Sqlite/Dameng do.

update demo_table
set updated_at = '2023-03-10 13:19:03.142798-09:00'  -- supported since MySQL 8.0
where id =  '01186883-7690'

So we have to use gtime.Now().Local().Time.Format("2006-01-02 15:04:05.999999") instead of gtime.Now().Time.Format("2006-01-02 15:04:05.999999-09:00") when setting updated_at/deleted_at as string.

This implemantion also requires the DB server(or docker container/host os) other than MySQL running at the same timezone as the client, otherwise the timestamp might be updated with wrong timezone (mostly UTC).

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

MySQL 5.7 does not recognize +07:00 in timestamp string, while MySQL 8.0 can.

[wesleywu]

Confirmed all DBMS drivers implemented in contrib/drivers can correctly parse string with format '2023-03-10 13:19:03.999999' into datetime/timestamp types.
I think this feature can be safely merged.
@gqcn

[wesleywu]

restore the default organization of imports

[houseme]

restore the default organization of imports

The unit test needs to add a test that is not six decimal places to verify that it can be written properly.

[wesleywu]

现在应该比较完美了

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

It should be perfect now

[wesleywu]

The unit test needs to add a test that is not six decimal places to verify that it can be written properly.

test added.

[gqcn]

@wesleywu Awesome!