APP_TIMEZONE deprecated?
Permalink
Is the define APP_TIMEZONE deprecated for 5.7? It cannot be set in application/bootstrap because concrete/bootstrap (where it is tested for existence) is executed before.
The only way to set it is in dispatcher.php or earlier, which makes me suspicious.
The only way to set it is in dispatcher.php or earlier, which makes me suspicious.
We should probably make this a setting you can set in the dashboard time zone page, as well.
That's a good idea.
I added this pull request for doing in the file config
https://github.com/concrete5/concrete5-5.7.0/pull/1293...
I'm not exactly sure yet all of it wraps together though.
I added this pull request for doing in the file config
https://github.com/concrete5/concrete5-5.7.0/pull/1293...
I'm not exactly sure yet all of it wraps together though.
That would be nice, it's quite useful when you can't change TZ on the server.
I'm curious about your thoughts of 'system' vs. 'app' time though. Some Localization\Service\Date methods are using 'system', even the new toDB method. Wouldn't 'app' be a more useful default since it's very explicit and defaults back to system if it doesn't exist?
Btw, it would be great if toDB had an option for specifying toTimezone as well. I'm storing all dates as UTC to minimize confusion, the default 'system' could lead to problems if the data is moved across time zones.
/Andreas
I'm curious about your thoughts of 'system' vs. 'app' time though. Some Localization\Service\Date methods are using 'system', even the new toDB method. Wouldn't 'app' be a more useful default since it's very explicit and defaults back to system if it doesn't exist?
Btw, it would be great if toDB had an option for specifying toTimezone as well. I'm storing all dates as UTC to minimize confusion, the default 'system' could lead to problems if the data is moved across time zones.
/Andreas
http://www.concrete5.org/community/forums/5-7-discussion/how-to-ove...
As for APP_TIMEZONE the current method is to simply define it in index.php