PHP 5.2+ has the functions to work on date and they automatically take care
of all the math for DST.
Our solution is currently to run the servers in GMT. We set the default
timezone to GMT in bootstrap.php
We have also 2 functions in the AppController:
public function toLocalTime($time)
{
static $is_init = false;
static $dtzGMT = false;
static $dtzUser = false;
if (!$is_init){
//Cache the timezone locally for all the length of the PHP
request
$dtzGMT = new DateTimeZone('GMT'); //GMT is OK?
$dtzUser = new DateTimeZone(isset($this->user) ?
$this->user['time_zone'] : 'GMT');
$is_init = true;
}
$dt = new DateTime($time, $dtzGMT );
return $dt->setTimezone($dtzUser);
}
And :
public function toGMT($time) {
return gmdate('Y-m-d H:i:s', strtotime($time));
}
The controller call toLocalTime on all the dates passed to the View. The
View can format the dates with the ->format(..) method of the DateTime
object.
The controller also have to call toGMT before passing the dates to the
controller.
So far it seem to work pretty well. What do you guys think?
I would be nice if we could automatize the process and to be able to avoid
that the programmer has to explicitly call these functions each time.
Best,
Chris
On Fri, Nov 18, 2011 at 1:45 PM, euromark <[email protected]>wrote:
> right
> you would have to convert it back again of course
>
> find() => behavior converts all to local time
> save() => behavior converts all to UTC (cake inserts new dates in UTC
> anyway)
>
> probably quite some overhead but it should keep it clean.
>
> as of right now I simply set the timezone fixed to LONDON/BERLIN in
> the core and will not deal with until absolutely necessary :)
>
>
>
> On 4 Nov., 14:55, Jeremy Burns | Class Outfit
> <[email protected]> wrote:
> > I was thinking of the new key to display a localised version, but keep
> the old one for editing; if you just convert it and then save the record
> it'd save the 'local' version, wouldn't it?
> >
> > Jeremy Burns
> > Class Outfit
> >
> > http://www.classoutfit.com
> >
> > On 4 Nov 2011, at 13:32, euromark wrote:
> >
> >
> >
> >
> >
> >
> >
> > > probably
> > > i wouldt apply new keys then, just override the old ones.
> > > if you don't change the current keys your forms will have to be
> > > modified.
> >
> > > There is no jack of all trades device for this, i guess.
> >
> > > setting the default_time_zone to your location only fixes the dtc
> > > problem for this specific country.
> > > not setting it (to UTC so to speak) would be the right way to go +
> > > above approach which will probably add some overhead.
> >
> > > I cant think of a different solution.
> >
> > > On 4 Nov., 14:15, Jeremy Burns | Class Outfit
> > > <[email protected]> wrote:
> > >> Couldn't you do an afterFind in a behaviour that sets new keys like
> 'LocalTime'?
> >
> > >> Jeremy Burns
> > >> Class Outfit
> >
> > >>http://www.classoutfit.com
> >
> > >> On 4 Nov 2011, at 13:04, euromark wrote:
> >
> > >>> maybe you can adopt some of this
> > >>>
> https://raw.github.com/jellehenkens/lemon_utils/master/View/Helper/Ti...
> >
> > >>> I am wondering:
> > >>> How do you guys handle the daylight saving time issue?
> > >>> Currently we face this problem in 2.0:
> > >>> - dates (created, modified, own ones) are saved without it (-1 hour
> > >>> offset from the current time)
> > >>> - returning them from DB, though, leaves them untouched (still -1
> > >>> offset)
> > >>> - using a time helper that is aware of timezones we can correct it
> > >>> back to 0 offset for output
> > >>> But what with forms that directly use the content of the DB? they
> will
> > >>> contain the -1 offset which can be confusing.
> >
> > >>> wouldnt it be better to modify the dates right when they come out of
> > >>> the DB to ensure all methods (controller, model, view level) use the
> > >>> same offset? and make sure they are modified back on save?
> > >>> or how do you handle it? manually adjust dates used in forms?
> >
> > >>> of course the same goes for more than just DST - complete timezone
> > >>> changes etc.
> >
> > >>> On 29 Okt., 06:17, Ryan Schmidt <[email protected]> wrote:
> > >>>> On Oct 26, 2011, at 01:25, Shanaka wrote:
> >
> > >>>>> I'm creating a web application using cakephp 1.2.6.
> >
> > >>>> Why would you use 1.2.x to create a new web app, and not 2.0? Even
> using 1.3.x would be better but I don't see why you wouldn't start with the
> latest and greatest. Converting your app later to use a newer version of
> CakePHP will involve non-zero effort, so I'd think you'd want to spare
> yourself that work.
> >
> > >>> --
> > >>> Our newest site for the community: CakePHP Video Tutorialshttp://
> tv.cakephp.org
> > >>> Check out the new CakePHP Questions
> sitehttp://ask.cakephp.organdhelp others with their CakePHP related
> questions.
> >
> > >>> To unsubscribe from this group, send email to
> > >>> [email protected] For more options, visit this
> group athttp://groups.google.com/group/cake-php
> >
> > > --
> > > Our newest site for the community: CakePHP Video Tutorialshttp://
> tv.cakephp.org
> > > Check out the new CakePHP Questions sitehttp://ask.cakephp.organd help
> others with their CakePHP related questions.
> >
> > > To unsubscribe from this group, send email to
> > > [email protected] For more options, visit this
> group athttp://groups.google.com/group/cake-php
>
> --
> Our newest site for the community: CakePHP Video Tutorials
> http://tv.cakephp.org
> Check out the new CakePHP Questions site http://ask.cakephp.org and help
> others with their CakePHP related questions.
>
>
> To unsubscribe from this group, send email to
> [email protected] For more options, visit this group
> at http://groups.google.com/group/cake-php
>
--
Our newest site for the community: CakePHP Video Tutorials
http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others
with their CakePHP related questions.
To unsubscribe from this group, send email to
[email protected] For more options, visit this group at
http://groups.google.com/group/cake-php
