Hi Erik,
> On Wednesday, March 6, 2002, at 05:11 AM, DL Neil wrote:
>
> > My 'rules' are simple:
> > If the date/time is for processing, keep it as a timestamp (consider
> > which type).
> > If the timestamp is being used to keep track of RDBMS activity,
then
> > use a TIMESTAMP column.
>
> By
On Wednesday, March 6, 2002, at 05:11 AM, DL Neil wrote:
> My 'rules' are simple:
>
> If the date/time is for processing, keep it as a timestamp (consider
> which type).
> If the timestamp is being used to keep track of RDBMS activity, then
> use a TIMESTAMP column.
By RDBMS activity, do you
Erik,
Apologies, I missed your reply in the mass of mailings and a rushed
start to the week...
> > The choice comes down to how you are generating the time data prior
to
> > its storage in the db, and how you plan to use it afterwards. If you
are
> > going to be doing lots of temporal processing
On Monday, March 4, 2002, at 07:22 PM, DL Neil wrote:
> The choice comes down to how you are generating the time data prior to
> its storage in the db, and how you plan to use it afterwards. If you are
> going to be doing lots of temporal processing in PHP, then UNIX
> timestamp is the way to g
Erik,
> PHP's mktime() function uses a timestamp that is the number of seconds
> since the Unix epoch. MySQL uses the MMDDhhmmss format for its
> TIMESTAMP column type.
>
> I'm not complaining that they're not the same, but curious as to which
I
> should use for storing timestamps -- does it
Just make sure that whichever way you choose, you always use the same style,
so things don't get messy.
Personally, I always use INT(11) MySQL columns and store the unix timestamp
and this makes things easy for me. The only exception is when storing dates
that are before 1970, but I very rarely h
6 matches
Mail list logo
