Is it a good idea to use timestamps

Rails
1

Timestamps are a number that counts the number of seconds from the epoch
date 1/1/1970.
I read somewhere on the
internethttp://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 ?

2

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
internethttp://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:

3

Matt J. wrote in post #1125222:

On Monday, 21 October 2013 13:24:47 UTC-4, desbest wrote:

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 J.

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.

4

On Monday, 21 October 2013 13:24:47 UTC-4, desbest wrote:

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 J.