You almost never want to create a table without defining any columns. So when you call the create_table method, you almost always want to pass a block, where you define all the necessary columns for your table.

In this video, I want to focus specifically on timestamp columns, which are a fundamental part of Rails applications. If we look at this CREATE TABLE statement, we’re creating our posts table just as we did previously, but this time, we’ve passed a block. Using our table object, we specify that this table needs timestamps.

Let’s run this and examine the SQL that Active Record generates. Once again, we’ve created our posts table with an ID column, but now we also have created_at and updated_at columns. Both are defined as datetime fields and both are NOT NULL, meaning they must always have a value.

How Active Record Handles Timestamps

To better understand how Active Record interacts with timestamps, let’s create an Active Record model for our posts table and test it. We define a Post class that inherits from ActiveRecord::Base, and Rails automatically infers the necessary details—we don’t need to set anything up manually.

Now that we have this Post class, we can create a new instance. Let's run Post.create and inspect the SQL statement generated. Here, we’re inserting a new record into the posts table, and this process will be covered in more detail in an upcoming video.

What I want to highlight here is how Active Record serializes timestamps when sending them to SQLite. We can see that Rails uses ISO 8601-encoded strings, which store datetime values with six degrees of fractional-second precision. Even though SQLite technically does not have a proper datetime type, it can still work with these values because they are stored as text strings.

Why ISO 8601 for Timestamps?

It’s worth noting that SQLite supports multiple datetime formats, including:

• ISO 8601 strings
• Julian day integers
• Unix timestamps

I believe Rails made the right choice by using ISO 8601 strings, as they are both human-readable and naturally sortable. This balance makes them perfect for production applications, where developers need to quickly interpret stored datetime values.

Active Record’s Role in Ensuring Data Integrity

Active Record ensures that datetime values stored in SQLite remain compatible with SQL queries, allowing for:

• Sorting by most recent updates
• Performing datetime calculations
• Using timestamps for analytics and reporting

One important detail is that the “6” in the type declaration indicates six degrees of precision in fractional seconds. However, SQLite itself does not enforce this precision—it will accept timestamps with any level of precision, whether it’s 3, 4, or even 15 decimal places. This notation is primarily for documentation and clarity.

One of the core principles of Active Record is that explicit is better than implicit. Even though SQLite is flexible in structuring data, we still want our CREATE TABLE statements to clearly define expectations for the table’s structure. This approach ensures that we always have a consistent understanding of how data is stored and retrieved.

In the next video, we’ll explore different column types that we can define when building a table for specific use cases.