Is it a good idea to use timestamps

rubyonrails-talk
1

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 ?

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 internet<http://en.wikipedia.org/wiki/Year_2038_problem&gt;, 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

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

4

Matt Jones wrote in post #1125222:

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

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.