[X] I had searched in the issues and found no similar feature requirement.
Description
Description
Why many time field in DB don't use the time type with time zone?
For example, using the t_ds_process_instance.start_time field, in PostgreSQL, the definition of field is timestamp DEFAULT NULL, in Mysql, the definition is datetime DEFAULT NULL. Both of them don't have the time zone information, and it stores the time value is as-is . I understand that this is by design, but it is not friendly for timezone switching and data migration scenarios.
In our case, when we switch the time zone from UTC to UTC+8, we lost the previous time information. In the admin UI, it looks like that all historical events were shifted 8 hours earlier.
e.g.
Is it worth considering adding timezone attributes to these database time fields?
Action
In Postgresql, changing the type from timestamp to timestamptz, in MySQL, change from datetime to timestamp.
Search before asking
Description
Description
Why many time field in DB don't use the time type with time zone?
For example, using the
t_ds_process_instance.start_time
field, in PostgreSQL, the definition of field istimestamp DEFAULT NULL
, in Mysql, the definition isdatetime DEFAULT NULL
. Both of them don't have the time zone information, and it stores the time value is as-is . I understand that this is by design, but it is not friendly for timezone switching and data migration scenarios.In our case, when we switch the time zone from UTC to UTC+8, we lost the previous time information. In the admin UI, it looks like that all historical events were shifted 8 hours earlier.
e.g.![image](https://github.com/apache/dolphinscheduler/assets/16267732/657bd999-f55d-46ad-9b10-eb28145f3a36)
Is it worth considering adding timezone attributes to these database time fields?
Action
In Postgresql, changing the type from
timestamp
totimestamptz
, in MySQL, change fromdatetime
totimestamp
.Are you willing to submit a PR?
Code of Conduct