[eluser]jedd[/eluser]
Hi brototyp,
I ws gng t gv my ntr rspns n sndx frmt, jst s y knw hw nyng t s .. but thought better of it, and hope that you stop abbreviating somebody as sb and something as south. Err, sth.
Anyhoo ..
I think you are on the right track with this approach:
Quote:2)Store Event dates in Database in UTC (GMT) and in unix format.
GMT is effectively the same as UT and UTC for the purposes of this discussion (unless you require something finer than 1s accuracy). You are unlikely to, however, unless you are quite particular. The Berlin reference suggests this is a possibility
In any case, let us proceed blissfully ...
The description of the process you are aiming at is spot on, insofar as how I'd approach it. The DB records
everything in GMT, and the application translates information back to the local timezone on the fly.
Timezone management is a bit problematic, though, as evinced by rapid changes (by which I mean < 2 months advanced warning for DST changes) over the past few years - the first biggy for me was 2k, with the advancement of DST by about 2 months for the Olympics in Sydney, but it happened again about 18 months ago where a timezone (well, DS) change occured with only a few months notice. How you acquire the TZ information is a bigger question, and depends to some degree on what OS you're on.
I digress.
The rest of your approach - users set their own TZ (presumably with the option to incorporate daylight savings in there - as some timezones argue about DS policy) - and so on, all makes good sense.
When you talk about 'sql format', are you talking about MySQL format for DATETIME or TIMESTAMP? Perhaps you should just consolidate on ISO 8601 - a quite fine format now the bugs have been ironed out.
Quote:For my introducing example: 1PM in New York - 7 PM in Berlin I get the right result(6 hours between New York and Berlin), but when i now use the Daylight_Saving Settings -> TRUE, my result turns into wrong (8 hours between New York and Berlin) !!!!!
I haven't cranked up the source you've provided, but will try to get to that tomorrow - to test on my system. It seems particularly odd - as you've observed - that it would screw up somehow, looking as though it's double-dipping on the DST affect.
Can you do a DB dump of the information going in, and the information taken (from a CLI) from the DB for those date fields, to give a hint on where the DST is getting added the second time?
Quote:But thinking about it daylight_saving settings can't be neglected, or can they ????.
Don't neglect DST. Novell did about 18 months ago, and pissed off several million people. Small-fry compared to the people they've annoyed in the previous decade, of course ...
I'm sure whatever problems you're seeing are reproducible and resolvable.
Quote:My servers (local) timezone is set Europe/Berlin but also changing this to in the php.ini to GMT didn't have any effects (I think it shouldnt because my solution doesnt need the servers time !?) I also set the config.php to $config['time_reference'] = 'GMT';
The server should be set to GMT in its hardware clock, but will have its own local timezone understanding (if it's a real OS, of course).
