refactor(db): Change timestamp column types to datetime
- Change start_time column type to datetime
- Change end_time column type to datetime
Just for my curious, what problem should these changes fix?)
Just for my curious, what problem should these changes fix?)
for "2038-01-19 03:14:07 UTC"
In general datetime nowadays is sure a better default for normal use. I wonder though if this is BC in this case.
In general datetime nowadays is sure a better default for normal use. I wonder though if this is BC in this case.
Overall, using DATETIME as the default is indeed a better choice for general use today. Regarding your concern about backward compatibility (BC), this has been addressed in the code. By introducing the FeatureFlags::$addTimestampsUseDateTime flag, the system can now dynamically choose between DATETIME and TIMESTAMP column types, ensuring that existing behaviors remain unaffected while allowing the improved default for new implementations.
@qnnp-me what if it would be possible to change column type automatically?) if feature flag is provided, of course. To update the existing table in the database.
@lutdev I agree with your approach. For new projects, setting the preferred column type early via the feature flag is ideal. For existing projects, automatically changing column types based on the flag could be risky and unexpected. Instead, developers can manually create and run a migration script when needed to update their tables. This keeps control with the developer and avoids unintended changes to production databases.
When I put out the next version with this PR, I will include in the notes on updating the phinxlog column types manually for those on older versions. I agree that I don't think it's worth trying to automatically migrate folks.
@MasterOdin Done. Ready for final review.