1. SO converts all timestamps to Api\DateTime objects using Api\DateTime::server2user($ts, 'object')
- Api\Storage and Api\Storage\Base class do that automatic if using 'object' as $timestamp_type constructor parameter
- if using just Api\Db you need to iterate over your selects manually and apply Api\DateTime::server2user($ts, 'object')
- timestamps are store in DB in server timezone and above conversation honors that and additionally set the user TZ
2. Rest of the app should keep all timestamps as Api\DateTime objects
- direct comparison works for Api\DateTime (and PHP \DateTime) as __toString() method automatic converts to UTC timestamps
- do NOT convert them to timezone-less timestamps and no further timezone conversation needed for output with eTemplate
3. eTemplate2 converts automatic to user timezone for displaying dates and times
- you need to use <date-time ... data_format="object"/> to get Api\DateTime objects back from eTemplate!
4. Api\Db converts automatic to server timezone when quoting DateTime objects for integer or timestamp columns
5. only output other then eTemplate might need to set a timezone different from the user TZ before calling $ts->format()
checking for the not existing (new) database runs into an invinit recursion
the checks not to use $_SESSION, if no session is active was added in an attempt to get SimpleSAMLphp discovery working, but seems unneccessary for what we currently use
MySQL and MariaDB before 10.1 need 4-byte utf8 chars replaced with our default utf8 charset
(MariaDB 10.1 does the replacement automatic, 10.0 cuts everything off behind and MySQL gives an error)
Changing charset to utf8mb4 requires schema update, shortening of some indexes and probably have negative impact on performace!
if (substr($this->Type, 0, 5) == 'mysql' && $this->ServerInfo['version'] < 10.1)
{
$value = preg_replace('/[\x{10000}-\x{10FFFF}]/u', "\xEF\xBF\xBD", $value);
}
