FlatPress Forums

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 these
global $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)

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.

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: 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 :)

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 28

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 46

I've had the same problem and you can fix it with a code in flatpress (found the solution @Heinrich Becker and translated it): http://blog.herkenhoff.com/2012/11/16/time-zone-problem-in-flatpress-solved/