NYCPHP Meetup

[David Sklar]

> D C Krook wrote:
>
> We're running Apache 1.3.27 with PHP as a DSO on Red Hat 7.3
> (2.4.20-18.7)

In this configuration, each apache child is a single-threaded process, so
you shouldn't have any threads-stepping-on-each-other problems. A given
child process (with its own environment) only handles one request at a time.

> Chris Shiflett wrote:
>
> I take a slightly different approach than what you mention. I can't
> say that I've ever given it a lot of thought, but this is what I do.
> I begin with some default variables for the application:
>
> $date_format = 'D, d M Y H:i:s';
> $gmt_offset = -4;
>
> If the user logs in, these values are overwritten with the user's
> session, so you can let your users choose their preferred date format
> and time zone.
>
> Then I just do something like this to get a ready-to-display date
> into a variable:
>
> $curr_date = gmdate($date_format, time() + $gmt_offset * 3600);
>
> Of course, this demonstrates a date relative to the current time, but
> this can be applied to any timestamp.

This works great most of the time, but it gets tripped up by Daylight Saving
Time because some users' GMT offsets change during DST. If you keep track of
the DST observance of a user, then you can adjust the GMT offset when
necessary. However, that "when necessary" can be tricky to figure out. If
you're just handling North American users, then you can switch users DST
status around the time when the server's DST status switches.

To be accurate around the time that DST status switches, however, you need
to adjust the user's DST status switch by the offset between the user's time
zone and the server's time zone. DST switches happen at a given hour in
local time, so at 2am PST, when things jump to 3am PDT (except, for example,
in Dawson Creek, BC, which doesn't observe DST) it's 6am EDT, because the
jump from 2am EST to 3am EDT happened three hours earlier, at 2am EST, which
is 11pm PST.

Other places in the world may switch between standard and summer time at
different times of the year. Some countries occasionally adjust their time
settings to make the Olympics run more smoothly. (see:
http://support.microsoft.com/default.aspx?scid=kb;en-us;257178).

The zoneinfo database knows about all these hinky time zone and DST issues,
which is what makes putenv() and strftime() a breeze. If you don't want to
use environment variables, though, I suppose you could store a zoneinfo zone
for a given user and then calculate the GMT offset for that user by parsing
the appropriate zoneinfo file and finding the DST setting and GMT offsets
that correspond to a particular UTC time. zdump(8) and tzfile(5) would be
helpful for that.

David