@diosmosis opened this Issue on December 11th 2018 Member

The logic in the Date class is strange and somewhat backwards. Multiple methods have documentation that contradict the actual methods, and sometimes the actual logic just doesn't make sense.

For example:

  • Date::factory('today', $timezone) takes a timezone, but does not return 'today in $timezone`, it returns 'the time in $timezone that is 'today' in UTC'. then it discards the timezone and treats the result as UTC.
  • Date::$timestamp is supposed to store the time in UTC, but in getTimestamp() it is treated as a time in another timezone.
  • getTimestamp() says it returns a UTC time, but it treats the stored time as non-UTC and converts it to UTC. getTimestampUTC() however just returns the timestamp. so getTimestamp() != getTimestampUTC() even though both say they return UTC time.

The API should be audited, trimmed and made coherent, but only for Matomo 4 since so much depends on this code.

Things that should be done:

  • [ ] timestamps should always be in UTC. timezones are just a view on that timestamp. so Date should not store a timezone and should not do any conversion in methods that return timestamps.
  • [ ] methods that take string representations or return string representations should accept timezones, eg: getDatetime($timezone = 'UTC'), toString($timezone = 'UTC'), Date::factory($value, $timezone = 'UTC')
  • [ ] since timestamps should always be UTC, Date::factory(...) should not accept timestamps (or should throw a if a timezone is specified w/ the timestamp). the semantics of Date::factory() should be, give me the posix timestamp of this date in this timezone. (ie, give me the UTC timestamp of 2012-03-04 03:05:23 UTC+5.
  • [ ] ...UTC() methods should be removed

Refs #13799
Refs #13786

@diosmosis commented on January 27th 2019 Member

Should also probably make sure the mysql session uses UTC instead of any other configured timezone.

Powered by GitHub Issue Mirror