Just to share a little bad experience from this morning.
Was fiddling on my server to make another script work properly and had to edit php.ini. Due some test the server ran a few seconds without the php.ini files. This was enough to blow up the timezone of my self hosted emoncms
All the graphs showed errors all over but that came back to normal once the php.ini file was re activated except that … saw it only half an hour later … my feeds didn’t update anymore
All the settings were reset to zero and thus the script couldn’t calculate timestamp …
Just setting back things correctly solved the case for me.
Still it is a bit weird that the settings rely so hard on server settings, can’t the settings be rather hard saved ??? Can imagine that with some heavy server updates or apache upgrades these settings just go blank … → loss of data
Can you confirm if you are using the default php.ini configuration? and in particular this section about halfway down.
[Date]
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
;date.timezone =
The fact this is commented out means that there should be no dependency on it.
As far as I know emonCMS uses only UTC globally for data handling and then each user account can have a local timezone derived in emonCMS from UTC from the clock of the host machine. the hosts local timezone is then used for things like logfile timestamps etc.
Server is cpanel driven and php.ini is pretty loaded for many reasons
the variable is not commented out
date.timezone = UTC
In this case if the server doesn’t give a zone (as in my case as php.ini was completely disabled for a few seconds) the script can’t match a non existing zone …hence errors. That I can understand. But what is less ‘normal’ to me, the setting is lost and you keep in error even when php.ini comes back normal.
