You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
this leads to wrong interpretation of dates (off-by-one) as the time is
changed. The native format used still contains the time information to
provide the timezone information for consumers. A short format like
'yyyy-MM-dd+00:00' is not being used even though php likes it other
parties interpreting that value might not like it. One example are api
consumers that get that native value or even elasticsearch which wants to
see something like "yyyy-MM-ddT+00:00". That would be parsed as military
Tango time though by php. That's why we sent the time info. Meh.
Suggestions are welcome. Applications can reformat according to their
needs on their system boundaries.
Future improvement suggestion: internally store the timezone of the given
values to have them available later on. This helps in migrating stuff when
eg.g the timezone db changes.
refs #28
This behaviour breaks expectations when one is not thinking about this. Example:
System is using UTC. PHP script sets default timezone to CET (+01:00). ValueHolder sets value as follows:
This input is treated as follows in
DateRule
:DateTimeImmutable
as2016-12-10T00:00:00.000000+01:00
2016-12-09T23:00:00.000000+00:00
2016-12-09T23:00:00.000000+00:00
2016-12-09T00:00:00.000000+00:00
This means we now have a date set internally that is off by one. 🎱
Suggested solution: don't set the time info at all or make it optional.
The text was updated successfully, but these errors were encountered: