Forum: Ruby on Rails Is it a good idea to use timestamps

Bcdd9f5447f1a3f18cefdb8c3f6b4dab?d=identicon&s=25 desbest (Guest)
on 2013-10-21 19:25
(Received via mailing list)
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 ?
280b78a61a968391b7e07e912be102a8?d=identicon&s=25 Robert Walker (robert4723)
on 2013-10-22 06:39
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...
6883e5ef03484d4fcef507d7b4f1d243?d=identicon&s=25 Matt Jones (Guest)
on 2013-10-22 16:39
(Received via mailing list)
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 Jones
280b78a61a968391b7e07e912be102a8?d=identicon&s=25 Robert Walker (robert4723)
on 2013-10-22 17:08
Matt Jones 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 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.
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.