Posted by Gordon Burditt on 01/20/07 06:59

>There's an "underlying" storage for dates? I wasn't aware that PHP had
>a true date type for a timestamp for "lie under."

It doesn't need a *TRUE* date type, it just needs some way to store
dates (and for the date library functions to use as input and
output). And a 32-bit integer is pretty lame nowadays. And that
seems to be what PHP uses for the date library functions (on 32-bit
machines, anyway).

>Timestamps are just
>integers.

This is not true in general, unless you're saying that "all bits
is just bits" and trinary is impossible. For example, in MySQL, a
timestamp has pieces year, month, day, hour, minute, and second.
In MS-DOS, a file timestamp also had these fields, but the number
of seconds was missing a bit so only even seconds were possible,
and the range of years were very limited. And some programs just
store dates as strings, with or without a time zone.

Oh, yes, it does matter whether a timestamp is implicitly in local
time, UTC, or something else. POSIX timestamps really have no good
way to store "the date of a transaction", meaning the year/month/day
local time a particular transaction happened. That date doesn't
change when the user moves from one timezone to another, and it can
have legal implications more significant than the UTC date/time.

>PHP may have a lot of functions for parsing strings into
>integer timestamps and building strings from those integers but that
>doesn't mean there's any trick to using representing a date with
>another data type.

There is if you have to re-create all the functions for dealing
with time because, say, they have insufficient range.


>I was just hoping that PHP would have something
>built in for storing dates in a format other than timestamps.

I consider "something built in for storing dates in a format" to
*BE* a timestamp by definition, even if it's not a POSIX timestamp.

>From the
>look of the parse_date() function I mentioned, it looks like something
>might be in the works but hasn't made its way to an official release
>yet.

>Actually, the PEAR libraries have a true date data type but I'm not
>sure where my app is ultimately going to be deployed so I'd rather not
>rely on it.
>

[Back to original message]