Is it a good idea to use timestamps

[desbest]

Timestamps are a number that counts the number of seconds from the epoch date 1/1/1970.

I read somewhere on the internet, that timestamps will expire in the year 2038.

This is why I always use yyyy-mm-dd and yyyy-mm-dd HH:ss to show the date and I don't use timestamps or time database columns.

 

Is it a good idea to use timestamps, or should I continue with yyyy-mm-dd HH:ss ?

[Robert Walker]

desbest wrote in post #1125087:

> Timestamps are a number that counts the number of seconds from the epoch
> date 1/1/1970.
> I read somewhere on the

> internet<http://en.wikipedia.org/wiki/Year_2038_problem>,

> that timestamps will expire in the year 2038.

> This is why I always use *yyyy-mm-dd* and *yyyy-mm-dd HH:ss* to show the

> date and I don't use timestamps or time database columns.
>
> Is it a good idea to use timestamps, or should I continue with
> yyyy-mm-dd
> HH:ss ?

This is only the case where the timestamp is stored as a 32 bit integer
value. AFAIK most modern systems use 64 bit integer values for this as
do not have the year 2038 bug.

I assume by "yyyy-mm-dd" you mean that you're storing dates as string
values. That is significantly less efficient that using datetime fields.

I would not worry about the 2038 bug. This problem will be fixed before
it becomes a problem if it is not already fixed in your database and
other related systems.

For example PostgreSQL stores its timestamps in 8 bytes (64 bits) and
has a range from the year 4713 BC to 294276 AD. So I think one would be
safe when using PostgreSQL timestamp.

Also of note is that the epoch for PostgreSQL is midnight 2000-01-01 and
not 1970-01-01. Not all systems use the same epoch.

In fact you'll find there are many different Epochs:

http://en.wikipedia.org/wiki/Epoch_(reference_date)#Notable_epoch_dates_in_computing

--
Posted via http://www.ruby-forum.com/.

[Matt Jones]

Depends on your database - in MySQL the TIMESTAMP column type is limited to 2038, but in others (Postgres, for one) this isn't the case.

If you declare your columns as :datetime in Rails migrations you'll get a type (regardless of database adapter) that doesn't have this problem.

--Matt Jones 

[Robert Walker]

Matt Jones wrote in post #1125222:

It's also important to understand the difference in behavior between
"timestamp" and "datetime" in MySQL. If a timestamp column is not
specifically specified in an update statement it will update itself to
the current system time automatically. The "datetime" data type will not
do that, rather it will keep its current value.

Basically, never use the "timestamp" data type in MySQL, unless you
really understand, and want its behavior. I never use it myself, and
Rails has no built-in support for it. If you ask for a date and time in
Rails migrations you'll get a "datetime" data type when using MySQL.
Trust the default ActiveRecord mappings.