# Working with Timezone

I’m always relying Ruby on Rails to build web application, I think it’s not enough for a developer because Rails has already handled all the things actually I need to know how to deal with by myself.

Since this project I’m doing during my summer internship, I decide to create web service with Sinatra framework, which is a very simple micro framework to build web application. Sinatra provide limited features for you. There are many details you need to notice if you switch from Rails.

## System

The time of computer is offered by OS(I don’t want to dig the details of hardware.), so let’s check how to get the system time. There are many functions to do that, here are ones for Linux and OS X I find in StackOverflow.

• [time()] returns the wall-clock time from the OS, with precision in seconds.
• [clock()] seems to return the sum of user and system time. At one time this was supposed to be the CPU time in cycles, but modern standards require CLOCKS_PER_SEC to be 1000000, giving a maximum possible precision of 1 µs. The precision on my system is indeed 1 µs. This clock wraps around once it tops out (this typically happens after ~2^32 ticks, which is not very long for a 1 MHz clock).
• [clock_gettime(CLOCK_MONOTONIC, …)] provides nanosecond resolution, is monotonic. I believe the ‘seconds’ and ‘nanoseconds’ are stored separately, each in 32-bit counters. Thus, any wrap-around would occur after many dozen years of uptime. This looks like a very good clock, but unfortunately it isn’t yet available on OS X.
• [getrusage()] turned out to be the best choice for my situation. It reports the user and system times separately and does not wrap around. The precision on my system is 1 µs, but I also tested it on a Linux system (Red Hat 4.1.2-48 with GCC 4.1.2) and there the precision was only 1 ms.
• [gettimeofday()] returns the wall-clock time with (nominally) µs precision. On my system this clock does seem to have µs precision, but this is not guaranteed, because “the resolution of the system clock is hardware dependent”.
• [mach_absolute_time()] is an option for very high resolution (ns) timing on OS X. On my system, this does indeed give ns resolution. In principle this clock wraps around, however it is storing ns using a 64-bit unsigned integer, so the wrapping around shouldn’t be an issue in practice. Portability is questionable.

## Library

We know there is a Time class in Ruby standard library. And I find the related code for Time.now in Rubinius.

We can see Ruby use clock_gettime or gettimeofday to get the system time. The time object return by method Time.now has no timezone information. But you will ask why I see thing like this 2015-08-14 15:20:41 -0400 in rib, that’s because Ruby will call the to_s method to display object to output. For Time class, the strftime method will be invoked, which handle the local timezone information.

## Web Framework

If we start a web application with Rails, we all know to set the time zone with config.time_zone, this configuration set the time zone of your application, and library ActiveSupport add some methods to get the time with the set time zone. Time.zone.now get the time at NYC if you have set the time zone through Time.zone = "Eastern Time (US & Canada)" or config.time_zone = "Eastern Time (US & Canada)". Or you can use Time.current to get the time of NYC if the time zone is set, otherwise you will get result of Time.now, which use your system time zone.

Here is the now method in TimeZone class of ActiveSupport.

And the core extension of Time class.

## Database

In web application, we use database to persist data. In Ruby world, thanks to ActiveRecord, the database ORM is so easy. But what about the time zone of timestamps stored in database?

ActiveRecord has a config to set the time zone, but it’s the time zone to store and parse the timestamps in database, the database has no idea with which time zone is it. ActiveRecord firstly exchange your passed time with the set time zone before store to database, and parse the time with that time zone after retrieve from database.

This is a description I find in postgresql documentation indicates that it database treats all timestamp as in UTC.

For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system’s TimeZone parameter, and is converted to UTC using the offset for the timezone zone

The best practice is to use UTC with ActiveRecord.

## Conclusion

One word to summarize the time zone stuff in development is, to unify your time zones in all layers of your software, and UTC is the best option.