DateTime, Timestamp, Time and Date in Rails

Learn about key differenece between DateTime, Timestamp, Time and Date in Rails
31 October 2017   6547

The difference between different date/time formats in ActiveRecord have little to do with Rails and everything to do with whatever database you're using.

Using MySQL as an example (if for no other reason because it's most popular), you have DATEDATETIMETIME and TIMESTAMP column data types; just as you have CHARVARCHARFLOATand INTEGER.

So, main differences: DATE only stores a date, TIME only stores a time of day, while DATETIME stores both.

The difference between DATETIME and TIMESTAMP is a bit more subtle: DATETIME is formatted as YYYY-MM-DD HH:MM:SS. Valid ranges go from the year 1000 to the year 9999 and everything in between. While TIMESTAMP looks similar when you fetch it from the database, it's really a just a front for a unix timestamp. Its valid range goes from 1970 to 2038. The difference here, aside from the various built-in functions within the database engine, is storage space. Because DATETIMEstores every digit in the year, month day, hour, minute and second, it uses up a total of 8 bytes. As TIMESTAMP only stores the number of seconds since 1970-01-01, it uses 4 bytes.

You can read more about the differences between time formats in MySQL here.

In the end, it comes down to what you need your date/time column to do. Do you need to store dates and times before 1970 or after 2038? Use DATETIME. Do you need to worry about database size and you're within that timerange? Use TIMESTAMP. Do you only need to store a date? Use DATE. Do you only need to store a time? Use TIME.

Having said all of this, Rails actually makes some of these decisions for you. Both :timestamp and :datetime will default to DATETIME, while :date and :time corresponds to DATE and TIME, respectively.

Ruby and Rails to Get New Updates

Six vulnerabilities in the RubyGems package management system are now fixed and three in Rails framework
14 March 2019   184

There are corrective versions of the Ruby 2.6.2 and 2.5.4 programming language, which eliminate six vulnerabilities in the RubyGems package management system:

  • CVE-2019-8324: the ability to execute code when installing an untested package (an attacker can place the code on the gemspec and this code will be executed via a call to eval to ensure_loadable_spec at the verification stage before installation);
  • CVE-2019-8320: the ability to delete directories through manipulations with symbolic links when unpacking tar files;
  • CVE-2019-8321: the ability to substitute escape sequences through the handler Gem :: UserInteraction # verbose;
  • CVE-2019-8322: the ability to substitute escape sequences through the command "gem owner";
  • CVE-2019-8323: Ability to substitute escape sequences in the API handler (Gem :: GemcutterUtilities # with_response);
  • CVE-2019-8325: The ability to substitute escape sequences through error handlers (Gem :: CommandManager # run calls alert_error without escaping characters).

In addition, an update was provided to the Rails 4.2.11.1, 5.0.7.2, 5.1.6.2, 5.2.2 framework. and 6.0.0.beta3 with the elimination of three vulnerabilities:

  • CVE-2019-5420 - potentially allows you to remotely execute your code on the server, when Rails is running in Development Mode. If there is information about the attacked application, you can predict the automatically generated mode token for developers, knowledge of which allows you to achieve the execution of your code;
  • CVE-2019-5418 is a vulnerability in the Action View that allows you to get the contents of arbitrary files from the server's file system by sending a specially crafted HTTP Accept header if the code in the "render file:" handler is present.
  • CVE-2019-5419 - DoS-vulnerability in Action View (MODULE / COMPONENT), allowing to achieve 100% load on the CPU through manipulations with the contents of the HTTP-header Accept;