Dolibarr
ADD tolerance for DST changes in holiday date validation
ADD tolerance for DST changes in date validation.
Instructions
This is a template to help you make good pull requests. You may use Github Markdown syntax to format your issue report. Please:
- only keep the "FIX", "CLOSE", "NEW", "UIUX", PERF" or "QUAL" section (use uppercase to have the PR appears into the ChangeLog, lowercase will not appears)
- follow the project contributing guidelines
- in particular, in case of a bugfix, please check that you are targetting the branch corresponding to the oldest version in which the bug occurs
- replace the bracket enclosed texts with meaningful information
FIX|Fix #[issue_number Short description]
[Long description]
CLOSE|Close #[issue_number Short description]
[Long description]
NEW|New [Short description]
[Long description]
UIUX|Uiux [Short description]
[Long description]
PERF|Perf #[issue_number Short description]
[Long description]
QUAL|Qual #[issue_number Short description]
[Long description]
We should not need such a pr as the input date of the function are always into UTC date as explained by the doc of function.
If yes, date are not sensible to dst time, if not, it means there is a bug somewhere else. May be you can describe how to reproduce the bug into a phpunit case.
please consider this data from a customer : 1758672000 , 1758844800 , FR , 1 = 0 1759363200 , 1759449600 , FR , 1 = 0 1759968000 , 1760054400 , FR , 1 = 0 1760486400 , 1760659200 , FR , 1 = 0 1761177600 , 1761264000 , FR , 1 = 0 Error Dates must use same hours and must be GMT dates 1761782400 , 1761865200 , FR , 1 = 0 1762387200 , 1762473600 , FR , 1 = 0 Error Dates must use same hours and must be GMT dates 1761782400 , 1761865200 , FR , 1 = 0 1759449600 , 1759708800 , FR , 1 = 2 1757894400 , 1758240000 , FR , 1 = 0 1760572800 , 1760659200 , FR , 1 = 0 1768780800 , 1769126400 , FR , 1 = 0 1757894400 , 1758844800 , FR , 1 = 2 1759363200 , 1759449600 , FR , 1 = 0 1760918400 , 1761091200 , FR , 1 = 0 Error Dates must use same hours and must be GMT dates 1764288000 , 1764457200 , FR , 1 = 0 Error Dates must use same hours and must be GMT dates 1764543600 , 1764547200 , FR , 1 = 0 1758067200 , 1758240000 , FR , 1 = 0 1757548800 , 1757635200 , FR , 1 = 0 1758153600 , 1758240000 , FR , 1 = 0 1759363200 , 1759449600 , FR , 1 = 0 1759881600 , 1760054400 , FR , 1 = 0 1760572800 , 1760659200 , FR , 1 = 0 1761177600 , 1761264000 , FR , 1 = 0 Error Dates must use same hours and must be GMT dates 1761782400 , 1761865200 , FR , 1 = 0 1762387200 , 1762473600 , FR , 1 = 0 1761177600 , 1761264000 , FR , 1 = 0 1756771200 , 1758240000 , FR , 1 = 4 1759708800 , 1760054400 , FR , 1 = 0 1760313600 , 1760659200 , FR , 1 = 0 1762128000 , 1762473600 , FR , 1 = 0 1762732800 , 1763078400 , FR , 1 = 1 1764547200 , 1766102400 , FR , 1 = 4 Error Dates must use same hours and must be GMT dates 1768176000 , 1769814000 , FR , 1 = 0
After analysis, it turned out to be a configuration error on their shared server, which hadn't defined a time zone offset, resulting in a one-hour difference.
The problem is that this check is critical and requires direct modifications to the database if the server is incorrectly configured. The key question, therefore, is whether we're willing to run this function on a poorly configured server, given that this check doesn't seem necessary at the function level.