chenxi-null opened a new issue, #16131:
URL: https://github.com/apache/dolphinscheduler/issues/16131

   ### Search before asking
   
   - [X] I had searched in the 
[issues](https://github.com/apache/dolphinscheduler/issues?q=is%3Aissue) 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.
   
![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` to `timestamptz`, in 
MySQL, change from `datetime` to `timestamp`.
   
   ### Are you willing to submit a PR?
   
   - [X] Yes I am willing to submit a PR!
   
   ### Code of Conduct
   
   - [X] I agree to follow this project's [Code of 
Conduct](https://www.apache.org/foundation/policies/conduct)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: 
[email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to