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 ? -- 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/4d302984-e55c-4233-a7a8-9f5108bd4e1e%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org 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.
On Monday, 21 October 2013 13:24:47 UTC-4, desbest wrote:> > 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 ? >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 -- 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/933b19e1-5650-4640-8993-38df2a9f9590%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
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 JonesIt''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. -- 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/ad72f8397a0416e3c00e551a6c4b7642%40ruby-forum.com. For more options, visit https://groups.google.com/groups/opt_out.