ℹ️
Welcome to the archive of the old FlatPress support forum. Browse more than a decade of FlatPress wisdom! Login is disabled.The current FlatPress support forum is available here: forum.flatpress.org
Setting the timezone
-
I was browsing the log from my web server, and noticed the following warning:
PHP Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /store/home/www/blog/flatpress-0.1010/fp-includes/core/core.date.php on line 95
Although this is pointing at the location of the mktime() call, it doesn't seem to be the right place to set the timezone. Perhaps fp-content/config/settings.conf.php is more appropriate. What is the right approach here ? -
I'd put it in flatpress/trunk/flatpress/fp-interface/lang/en-us/lang.conf.php I guess the *proper* way would require to turn these lines in core.date.php
$arr['time'] = mktime($arr['H'], $arr['M'], $arr['S'], $arr['m'], $arr['d'], $arr['y']);into theseglobal $fp_config; $arr['time'] = 60*60*$fp_config['locale']['timeoffset'] + gmmktime($arr['H'], $arr['M'], $arr['S'], $arr['m'], $arr['d'], $arr['y']);so that *ANY* date is interpreted as a GMT date offset by the value in the option panel but this would probably break old entries (but it would break only their displayed date, so it might not be that big a deal for you) -
I'm not sure that I agree that this is quite entirely the right approach. Generally speaking, my experience has been that date records and timestamps should be stored as UTC. Dates should be shown in local time where appropriate. To accomplish this, a mechanism such as the TZ variable in tzset(3) should be used because the rules to accomplish the transformation from UTC to local civil time are somewhat arcane especially when it comes to Daylight Saving Time. A simple UTC offset simply isn't expressive enough in the general case. Thus to obtain local civil time, mktime() (or similar) is the right general approach and is preferred "rolling-your-own" UTC to local civil conversion. I'm also not so sure about your suggestion to put this in lang/en-us. This is not a language issue, it's an issue of geography. I may want the display to be in English, but my server might be located in Asia.
-
There is no 'right' place to put that info into, at the moment. settings.conf.php is wrong because it may be overwritten by the web interface, while the lang files are relatively static, and you could temporarily hardcode there the call to date_default_timezone_set(...). I'm just saying that if I were in you, that's what I'd do. If there were a setting for that, the value would be probably stored in settings.conf.php and the date_default_timezone_set() would be probably called somewhere around system_init() but it is not. not at the moment, at least. I hope my explanation clarified the reason for which things work the way they do. bye :)Of course what you are saying makes sense. Still, while I value your suggestion, , most of the local/time-date logic has been inherited from SimplePHPBlog, and it has been kept for compatibility. For instance, FP uses the file system to infer some pieces of information (e.g. which/how many entries are there for 2010, June ?) making the date UTC might lead to get those pieces wrong. e.g.: you have an entry entitled 'Hi, guys' written on 2010-06-01 01:00:00 UTC but you live in NYC, so for you it's 2010-05-31 20:00:00 so if you query for /your-flatpress-install/2010/05/ you would expect to see 'Hi guys' on the top, but it won't, because that post it is not filed under /10/05/, but it is in fact in /10/06/entry100601-000000.txt Now your post could anyway *display* the date with the correct offset, but still it would be filed incorrectly. This is one of the reasons to encode the offset information right in the timestamp Remember, we are *not* using a conventional database. If you think you have any idea to fix this behavior while retaining backward compatibility, feel free to propose a patch.
quietdragon said: Generally speaking, my experience has been that date records and timestamps should be stored as UTC. Dates should be shown in local time where appropriate. To accomplish this, a mechanism such as the TZ variable in tzset(3) should be used because the rules to accomplish the transformation from UTC to local civil time are somewhat arcane especially when it comes to Daylight Saving Time. A simple UTC offset simply isn't expressive enough in the general case.
quietdragon said: I'm also not so sure about your suggestion to put this in lang/en-us. This is not a language issue, it's an issue of geography. I may want the display to be in English, but my server might be located in Asia
Phew! That's my first problem fixed! I successfully made error on line 14 disappear thanks!
Onto line 47.
It's tough going this stuff for an html web designer.
That backend room is dark and complicated!
Update: That only fixed one of the date/timezone issues in core.date.php - still two errors to go there:
Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'GMT/0.0/no DST' instead in /Users/anwarchoukah/Sites/created_by/flatpress/fp-includes/core/core.date.php on line 28Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'GMT/0.0/no DST' instead in /Users/anwarchoukah/Sites/created_by/flatpress/fp-includes/core/core.date.php on line 46
I can't find anything about it on the web, either...
Any help, greatly appreciated..
I'm running a test server locally on my MacBookPro, built-in web server on OS X 10.7.2, allowing php5, if that helps any?
Thanks again,
Anwar
