in General

PHP5 vs. daylight saving in Ubuntu 8.04.1 LTS

Much of Australia went into DST mode this week, with the only holdouts being the odd little backwaters of our country (generally referred to as “Queensland”) for whom daylight saving is a threat to curtains or farm animals… and anyone relying on PHP5′s bundled timezone database.

I filed a bug and test case regarding the problem (which will hopefully be be fixed with an official update, given that Hardy is an LTS release), but here’s a quick guide to work around the problem in the mean time. Thanks to Andrew “ajmitch” Mitchell for pointing me in the right direction!

  1. Grab and unpack the timezonedb extension tarball from PECL.
  2. apt-get install php5-dev
  3. phpize
  4. ./configure --with-php-config=/usr/bin/php-config5
  5. make
  6. sudo cp modules/timezonedb.so /usr/lib/php5/20060613/
    Note: The precise name of the final directory might be different. For instance, on hardy-i386 it will be 20060613+lfs.
  7. sudo vi /etc/php/conf.d/timezonedb.ini
    Yes, this is a new file. Content: extension=timezonedb.so
  8. sudo /etc/init.d/apache2 force-reload

Now your PHP has the very latest timezone data up its sleeve, so you can rest easy knowing that your web visitors won’t think you’re a Queenslander.

Zing! :-)

Update: The php5-timezonedb extension was added to Debian, but removed from intrepid… seems it was because intrepid’s php5 has a patch to use the system tzdata. It would be awesome to get that patch into hardy!

Update: Uh, what about make…? :-)

Write a Comment

Comment

Comments will be sent to the moderation queue.

14 Comments

  1. Oh weak ! Pick on the northerners.

    If you were in Queensland, you’d never have had this bug ! Although I do feel sorry for those people who don’t live in Queensland, having to “save” daylight, must be tough running short.

  2. Note that Western Australia didn’t switch to DST over the weekend either.

    While we have been trialing this quaint daylight saving idea for the last three years, it seems the state government didn’t feel it necessary to synchronise the transition dates with the eastern states (which is a bit stupid, given that synchronisation was one of the reasons put forward for the trial). Hopefully this is the last year we’ll have to care though …

    As for the actual problem, any program that is time zone aware but not using the system time zone database should be considered buggy. It is hard enough getting one database updated — not having the app use those updates is crazy.

  3. @James Henstridge: Yeah, I was surprised when I found out this was due to a separate time zone database. I remembered you and Martin Pitt had done quite a bit of work to fix that elsewhere (Python, etc). There’s always another bug to shoot down… :-)

  4. No, using the system timezone database is a really bad idea. I’ve tried talking sense into the original developer of that patch (it first made it into RedHat) but he wouldn’t listen. This patch to use the system tzdata won’t work from PHP 5.3 and up anymore anyway – as PHP adds extra information to it that the system tzdata does not provide.

  5. @Derick Rethans: Aside from the 5.3 issue, why is it a “really bad idea”? I can’t think of a case in which it would be more sensible to use a separate datasource that may get out of sync (and thus require more oversight and maintenance on behalf of the distributor — upstream or otherwise).

    In terms of 5.3, perhaps the patch can be reworked to “fall up” to provide the additional information as sugar on top of the system time zone database.

  6. I once heard that all the ISP shaping and quota scripts were written in PHP. I normally schedule big downloads to start at 12:05am, which is when our offpeak quota starts.

    Interestingly, I noticed that when daylight saving started, for the first hour of my scheduled downloads, they were counted as peak downloads. I now start my downloads at 1:05am. ;)

    I wonder if this was caused by that PHP bug.

  7. Yeah, that too. Reminds me of a classic exchange from two former co-workers of mine:

    – Ack! I just spent 30 minutes tracking down…
    – … a 1-character problem?
    – Yeah, it seems that (in PHP) a null string evaluates to 1… There should be some kind of warning about that…
    – Such as: Warning: why aren’t you using Perl?

    The irony of Perl being saner than PHP (or, well, pretty much anything) is not lost on me.

  8. @Derick Rethans:

    What kind of extra information will PHP 5.3 provide that can’t be read from the system’s tzdb?

    Also, you said:

    (in the thread)
    > Why do you need this? There is the PECL timezonedb extension which is
    > updated just as frequently.

    (here)

    > I am often also quicker releasing a new timezonedb package than debian is with their > tzdata stuff.

    Right, but only when you *do* update it (though IIRC you once took almost a month to update the extension wrt the Oslon database). In 2007 you missed a, d, f, and g.

    I do understand that it is more convenient to ship an embedded database because of compatibility with windows, and such; but it doesn’t apply to every situation.

    Oh, and as Sean Finney stated in the thread, we – actually *I* – packaged the PECL extension but we soon dropped it in favour of the patch; which translated into one less thing to spend/waste time on.