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/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/75d947d37ecf06533531ee37436ed701%40ruby-forum.com. For more options, visit https://groups.google.com/groups/opt_out.
