Hi Justin,
Thanks for your reply. Actually the main issue that I'm running into is
that I cannot get Unix timestamps before 1970. I'm running on Red Hat
Enterprise Linux (kernel 2.4.21-20.EL). If I run:
<?php
echo strtotime('1950-01-01');
?>
the script outputs "-1", which then of course translates to 1969-12-31.
According to http://us2.php.net/strtotime, it says "... dates prior to Jan
1, 1970 will not work on Windows, some Linux distributions, and a few other
operating systems".
I'm guessing Red Hat Enterprise or at least the kernel I'm using (which is
the latest RH kernel) qualifies under the Linux category above. Also, with
the application I'm writing, I need to deal with dates after 2038 too. So
that is why I'm investigating alternatives - just because I'd like something
that would definitely work on any platform and is 'official' as much as
possible - rather than have my date handling be OS-specific.
Thanks,
Ryan
"Justin French" <justin.french@xxxxxxxxxxxxx> wrote in message
news:1EDD556E-3778-11D9-A9A4-000A9579CE3A@xxxxxxxxxxxxxxxx
> On 16/11/2004, at 7:05 AM, Ryan wrote:
>
> > I would like to find out the 'official' way to handle dates in PHP. I
> > am
> > aware of the limits on a Unix timestamp, but I am writing a financial
> > application that needs to deal with dates both before 1970 and after
> > 2038
> > and of course have run into problems when trying to format those dates
> > using
> > the date() and strftime() functions. This of course then also impacts
> > Smarty as Smarty's date_format modifier is just a wrapper around
> > strftime().
>
> End of the day, you need to choose something which works for you.
> There's no right answer, but there's some good answers :)
>
> I store everything in GMT. If I need to know more about the timezone
> of the object, I'll either store the local time, or the offset from
> GMT. I choose to store everything as a MySQL DATETIME (YYYY-MM-DD
> HH:II:SS), because it's human readable, easy to convert to a unix
> stamp, and more portable across platforms (eg Windows), although it
> does use a few extra bytes.
>
> It's also important to note that (at least for Unix) Unix timestamps do
> work pre-1970... they are just a negative integer, so you need to allow
> for signed integers in your database if that's the format you choose to
> use.
>
> I've spent a lot of time working with dates and times, trying to
> understand it all and come up with a solid process. You need to really
> read the manuals and understand what you're storing, and what you're
> doing with functions like date() which assumes a GMT stamp, but outputs
> a TZ-corrected date.
>
> > I am looking at the PEAR Date module and that seems to resolve these
> > issues,
> > but I would like to know if that is the standard/official way to handle
> > dates in PHP applications as in my application, I would like to have
> > one
> > handler for dates, rather than separate code for dates within the Unix
> > timestamp range and for dates outside - so if I switch to PEAR Date, I
> > will
> > use it everywhere in my code since I cannot take any chance of using
> > date()
> > or strftime() and possibly getting invalid data.
>
>
> I've never worked with the PEAR modules, but my recommendation is this:
>
> - store everything as GMT, and store an offset if needed, and
> understand what it is you're storing
> - transport your dates in your scripts as GMT as long as possible (this
> is what date() and strftime() expect anyway)
> - understand when you want to use date(), and when you really want
> gmdate()
> - write some wrapper functions which you understand implicitly, so that
> you can deal with your data in a way which makes sense to you
>
>
> The catch here is if you use Windows for either development or
> production. I have zero experience with this platform, and don't know
> how much of my knowledge applies in that situation.
>
>
> Feel free to ask a detailed question to get a detailed answer :)
>
>
> Justin
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
