I mean, you create some migrations, build some models, make some API calls, but then time shows up and brings down the party. I happened to learn all about programming’s royal pain in the ass while working with the Instagram API last week. After I finally got my code working, I took a look at my JSON response and saw this strange creature:
Yeah, I didn’t know what that was either. So I went down the rabbit hole and learned about all the different things there are to know about dealing with time in your Rails applications. So save yourself some time (HAHA get it, get it?) and get the lowdown below.
In The Beginning, It Was…1970?
Okay, so you know that weird JSON response I got? The one that looked like this crazysauce:
Well, believe it or not, that’s not just a random number – it’s a representation of time. When I first saw this in my API reponse, I knew that this definitely was neither a typical Ruby
Time object, nor something I’d ever seen in any of the databases of my Rails applications (which usually uses the
So, I asked the interwebz for help. It turns out that this format is something called Unix time (also sometimes referred to as POSIX time or Epoch time). Unix time is short for the “Unix Epoch”, which is what we refer to when we use Unix time formats. Basically what you need to know is this: when the first computer turned on at 00:00:00 Coordinated Universal Time (UTC) on Thursday, January 1st, 1970, time officially began. I mean, time just started. The computer turned on and BOOM! It just started counting.
If you’ve ever played around in irb, you’ve probably used this method to figure out what time it is:
1 2 3
But that’s just one format of dealing with time. Want to know what time it is in the Unix Epoch? Simply apply the ever-handy
And what if you want to convert a Unix timestamp (like the one in my JSON response) back to a Ruby
Time object? Just use the
Okay, okay – but what about all the stuff that happened before 1970? How do we account for that? I’ll tell you how: NEGATIVE. NUMBERS.
Pretty sweet, right? Don’t worry; I’m about to complicate it a bit further.
Even More Types of Time
Another very common format for handling Time is ISO8601. There have been a lot of arguments in favor of ISO8601, its YYYY-MM-DD formatting being one of the foremost reasons for that debate. The ISO8601 format is also supported by various libraries, and can be sorted easily, which makes it the ideal candidate for your database.
An important thing to remember about using ISO8601 is that it’s part of the Ruby Standard Library, which means you must require it. (If you missed my explanation on the difference between the Ruby Standard Library and the Core Library, head over to last week’s post to catch up.)
But if we play with ISO8601 in irb, you’ll notice something kind of strange:
1 2 3 4 5 6
Z at the end of the string? That’s how the
UTC time zone is represented in ISO8601, with the
Z short for “Zero” time. It’s also worth reminding ourselves that Unix timestamps are also set in the
UTC time zone.
Goddamn Time Zones
Look man, I’m not gonna lie to you: time zones will jack your shit up. Time zone bugs are so common, it’s like they’re just waiting there patiently, hoping that you’ll make a mistake.
But you’re a Rails developer – ain’t no time zone gonna stop you! Instead, you’re going to make your code defensive and subscribe to these best practices:
Set your time zone in the
config/application.rbfile in your Rails app. Look for
config.time_zone, and configure your time zone equal to that value. Rails will refer to that as your base time zone going forward, and ActiveRecord will convert between `UTC and your set time zone whenever you query.
in_time_zonemethod to convert
Timeto your system’s current set time zone. For example,
Time.currentwhenever you make an ActiveRecord query (ActiveRecord will convert
Time.currentand convert it to
Comment.where(["comments.published_at > ?", Time.current])
DO NOT use
Time.now! This returns your system’s time, and ignores whatever time zone you configured for your Rails app. Instead, use numerical attributes and methods (such as
Date.current), which rely on the time zone you configured in your
application.rbto determine the return value.
There are a lot of loopholes when it comes to dealing with Time zones. You can read more about them on this super helpful post.
Time: Annoying, But Also…Awesome?
Ok, don’t get me wrong – time makes our lives miserable as developers. But it also presents some pretty epic challenges, which also makes our jobs interesting! (Look, I’m trying to point out the silver lining here.)
For example, leap seconds. Yes, really – it’s a thing. Leap seconds occur 1-2 times a year, on either June 30 and/or December 31st. They’re necessary in order to keep the Earth’s time of day close enough to the Sun’s mean time. But, how do you account for this in programs? Well, Google actually does something pretty cool: instead of adding one second, Google’s servers implement “leap smears”, which extend the seconds surrounding a leap second by just a little bit – enough to account for an entire extra second! Side note: the next leap second is on June 30th of this year! I hope you’re ready.
Another bizarre thing is Y2038. If this sounds reminiscent of Y2K, that’s because it is. Essentially, the 2038 problem boils down to this: On January 19, 2038, Unix timestamps will stop working because of a 32-bit overflow. So, all of the millions of applications that use this time format will have to either reconfigure to 64-bit systems, or choose a new format to store dates and times. There’s supposedly no universal solution to this, but hopefully someone will figure out a fix in the next 22 years.
Hopefully by that point, someone will have figured out how to get rid of time zones completely.
- Unix timestamps and ISO8601 are both good formats for storing date and time in your database. Do a little research to decide which of these formats is the best tool for whatever job you’re trying to accomplish.
- Dealing with time zones is hard, but the Exhaustive Guide to Rails Time Zones will save you hours of banging your head against the wall – well, for time-related things, at least.
- Want to be a
Timeobject superstar? Read this post, which was featured on HackerNews, and peruse the Ruby documentation to get the skinny on all things time-related.