UTC is Enough for Everyone, Right?

by Zach Holman

Summary of "UTC is Enough for Everyone, Right?"

In his talk at RubyConf AU 2018, Zach Holman explores the complexities of programming with time. He emphasizes how challenging handling dates and timestamps can be, emphasizing the common advice to use UTC (Coordinated Universal Time).

Key Points Discussed:

The Challenge of Programming Time: Holman shares anecdotes about the difficulties of dealing with time in programming and states that despite common belief, using UTC is not a panacea for all time-related issues.
Philosophical Perspectives on Time: He starts with a philosophical question: "What is time?" and delves into history, discussing the evolution of timekeeping from astronomical clocks to atomic time standards. He presents fascinating historical references, such as the standardization of time in the 1880s due to the railroad industry’s needs.
Time Zones Create Complications: Holman explains the emergence of time zones and their illogical aspects, including the absurdity of certain regional laws affecting timekeeping, like those in Florida or the decisions made by Samoans which led them to skip dates. He illustrates how such discrepancies complicate programming substantially.
Recommendations for Developers: The speaker stresses the importance of storing all timestamps in UTC and suggests maintaining a separate field for timezone information in databases to manage displays accurately later. He advocates for using ISO 8601 formatting for clear communication of time data.
Utilizing Libraries for Efficiency: Holman recommends leveraging established libraries, like Moment.js and Chronic, to handle date manipulation and natural language processing related to time queries, thereby avoiding reinventing the wheel.
Handling Recurring Events: He advises against creating individual records for recurring events and suggests utilizing efficient rules and frameworks to manage scheduling without over-complicating the logic.

Conclusions and Takeaways:

Use Standards: Developers should adhere to standards like ISO 8601 and UTC to manage time effectively in their applications.
Embrace Simplicity: Simplifying the way time data is handled can lead to increased efficiency and reduced headaches in programming.
Recognize Limitations: While time programming can feel overwhelming, many solutions have been derived from historical complexities, encouraging developers to leverage these lessons in their coding practices.

Holman concludes with a humorous critique that while one should never build a calendar unsupervised, understanding these nuances can make time programming significantly more manageable.

This talk offers valuable insights into the intersection of time and programming, reinforcing that complexity should be handled with established standards and reliable tools.

00:00:00.030 That is a developer from San Francisco. Some random facts about him, if you're interested in public speaking: I know it's old, but he has a it's still at Stuyvesant maturity. He has a website called speaking.io, which I've used in my talks. I'll take that information.

00:00:18.150 He was one of the first engineering hires at GitHub, and he's currently the founder of a new startup called During, which focuses on calendars and dates. He's here to speak about dates—something that we all grapple with on a daily basis. Thank you for coming all the way to this conference.

00:01:04.790 So it is time to talk about time. I feel like this talk should be called 'Crappy Jokes and Puns About Time.' Strap yourself in! Every time I've talked to somebody this week, they'd be like, 'Oh, what are you speaking on?' And I would say 'Programming time.' Usually, I think every single person responded with, 'Oh yeah, we kind of know this already; time is really hard to work with.' You spend your first weeks in programming realizing how challenging time is. It is not just a language thing; it's more complicated than that.

00:01:48.140 It’s not as simple as doing a Ruby gem install to fix all your problems, and JavaScript won’t solve your time-related issues, either. If you start writing in JavaScript, you'll introduce even more complications. We all have to deal with timestamps and date stamps, and we can't hide from it. It shouldn't terrify you; just use UTC, as people often say. Spoiler alert: that’s not wrong. I’m not going to say that UTC is a bad choice, because it can help you, but it's just normal advice found across every blog post, Stack Overflow post, and so on.

00:02:19.440 There are many complicated aspects to consider when we talk about time programming. So, that is what I will talk about today. I'm Zach Holman. Here’s a picture of me and my cat. It's actually a metaphor where I represent programming time, and my cat represents how terrified you might feel about it. A little humor aside, I actually got this photo taken by a photographer who kills me every time with laughter.

00:02:52.940 Once upon a time, I worked at GitHub for a long while. There was this running joke between a coworker and me. I just never understood how to build calendars and schedule meetings. It’s a massive headache. If I were an idiot, I’d probably go out and build a calendar startup, but I’m not. I started working on this new calendar solution last year. Like any calendar project, I ran into all sorts of edge cases while dealing with programming time. I've spent a lot of time thinking about this—so much so that I actually started jotting down things I wanted to discuss nearly a year ago.

00:03:44.000 There are a lot of weird aspects to this topic. So, today, I'm going to cover three main things: first, what is time? Let’s get philosophical; secondly, why is this so hard? Finally, I will dive into how we can use our code to tackle this challenging concept called time.

00:04:29.190 So, philosophically, what is time? Well, that's a question as old as time. It turns out I have a valid question to ask: does time actually exist? There are scientists who study this, and at the quantum level, something can slow down, and maybe none of this stuff even exists. Honestly, I don't have enough time to dig into these theories, but we don’t have to care about that. We exist, and I think that's good enough.

00:05:18.680 Here's a quick timeline of time, if you will. Around 4000 BC, we started using astronomical clocks, which gave us a little bit of an idea of what to expect throughout the day. By 1500 BC, we had sundials introduced as subdivisions of time. Before this, we basically just knew about day and night and observed the patterns outside. By the 14th century, fixed hours were established for the first time, with time no longer variable and affected by seasons.

00:06:15.800 Most of what I'm going to discuss today can be attributed to the needs of farmers, who had to coordinate their activities around time. By the 16th century, we had minutes; before that, we didn’t regard them as necessary. In the 17th century, we began measuring seconds. In 1883, in the United States, standardization of time began, largely driven by the needs of the railroad industry which required coordination.

00:06:50.800 So, a bunch of old railroad employees gathered in Chicago at a fancy hotel and decided to standardize time. They communicated this change over telegraphs across the U.S. This was a pivotal moment because we started to understand and agree upon what time really is.

00:07:21.330 In 1967, we moved closer to atomic time standards. If you're wondering, a second is defined by 9,192,631,770 energy transitions of Cesium. This has helped enhance accuracy to the point where we can lose about one second every 1.4 million years, which basically breaks down to losing about two nanoseconds a month. That’s why I blame time for being late to all your meetings.

00:08:03.700 We're getting better with optical clocks that tick a hundred times faster than atomic clocks. If you start one at the Big Bang fourteen billion years ago, until now, it would have only lost about 100 seconds. None of this stuff matters in your Rails apps again, but I just find it fascinating.

00:08:33.860 As we venture on, we face a simple question: what time is it? We often say something like, 'What time is it? How long is this going to go on?' But the implicit question here is, 'What time is it here?' For a long time, it was reasonable to ask this because we couldn’t travel too far. I could run fast, but time would remain constant for my short distance.

00:09:02.570 However, once we introduced airplanes, trains, and automobiles, the questions shifted to, 'What time is it over there?' This question became crucial when coordinating time across long distances, complicating the overall time for everyone. Before time zones were adopted, it was much simpler. This concept brought with it various complications.

00:09:49.850 To fix this, we said, 'Okay, let's create time zones.' Naturally, we divided this logically since there are 24 hours to a day and thus 24 expected time zones. However, nothing has turned out to be that simple; we actually have 39 time zones!

00:10:14.070 Time zones have been added gradually, often haphazardly. Take Florida, for instance; some crazy Florida lawmakers decided to stick with daylight savings time permanently. This means we have to adjust everything related to time all over again just to accommodate Florida's decision.

00:10:45.890 Time zones can be very illogical; they aren't simply +1 or -1 hour shifts. Some zones have 30-minute offsets; others have 45-minute offsets. Essentially, it's just a weird system we've built over time.

00:11:08.700 This is where the challenges of programming time arise. Unlike other programming issues, this one is particularly tricky. Historically, humans have struggled for eons to coordinate time effectively. You might describe the issue like having a beautiful house while the foundation is terrible—time-related problems stem from this unstable foundation.

00:11:53.360 Quick sidebar: close your eyes and recall five things you did on December 30, 2011. It's tough, right? This is because Samoans skipped from December 29th straight to December 31st due to an adjustment to effectively synchronize with their trading partners like Australia and New Zealand.

00:12:35.210 The geographical proximity of American Samoa and Samoa has resulted in two different time zones. American Samoa is UTC-11, while Western Samoa is UTC+12. They're about 800 kilometers apart.

00:13:01.630 In 2012, a decision was made to adopt daylight savings time in Samoa, while American Samoa continued to observe standard time. This has created further complications. Historically, this wasn’t the first time Samoans faced these challenges; they shifted their calendar twice in the past due to trading pressures.

00:13:48.520 Reflecting on the systems we’ve built, we realize time is exceedingly complex. One quick example involves Russia, which switched from the Julian calendar to the Gregorian calendar. During the 1908 Olympics, the Russian shooting team's members arrived 12 days late due to this calendar switch.

00:14:34.340 The Russians had been 12 days late previously as well, so they clearly did not learn from history. Time is incredibly complex, and I could give you countless examples of these complications. I simply didn’t have enough time to include all of them.

00:15:22.750 Now, transitioning to code, how can we effectively manage all these complexities? The key piece of advice is to use UTC, because at some point, you'll need to store and display time. It's critical to store everything in UTC and maintain consistency across your servers.

00:16:02.800 If you don’t require high-precision time, carefully assess what time is necessary for your application. For example, birthdays don’t require an exact time—having just the date is typically acceptable.

00:16:49.370 If you must record precise timestamps, you'll find it beneficial to store the timezone as well. For instance, having a separate field to keep the timezone in your database makes accessing this information easier later.

00:17:21.830 It's recommended to use the full IANA qualifier for time zones alongside your actual timestamp in the database. This ensures you’ve got accurate and relevant information for user display.

00:18:02.170 If you have to deal with the user side, you should maintain consistency. Whether it's a public API or a web application, ensure the time data is presented in a coherent way. The best approach is to use ISO 8601 as your standard for formatting time data.

00:18:45.090 Ruby developers know that when formatting time, using proper methods is essential for sorting and clarity. This will facilitate better understanding from both users and applications regarding what time means without ambiguity.

00:19:20.620 Next is about formatting time. The format of time can be problematic since different cultures and countries have different standards. It's always best to use user preferences for displaying date and time. Another option is to rely on existing libraries to handle localization, as they provide precise functionality without the need to reinvent the wheel.

00:20:02.890 One great option is to use a library like Moment.js, which simplifies date manipulation immensely. It allows developers to add or subtract from date formats easily, providing much-needed efficiency.

00:20:39.270 For relative time formats displayed on websites, they can present challenges and may not always be updated appropriately. A solution to this problem is utilizing the title attribute to display precise timestamps for improved clarity.

00:21:23.160 Additionally, when inputting time into forms, it's often pretty chaotic. Thankfully, browsers are starting to support better input types for date and time. While native date and time selection tools may vary by browser, developers should strive to create forms that gracefully manage inconsistencies.

00:21:54.620 One of the major issues is having a reliable time input solution for users, which often lacks standardization across different coding frameworks and environments. Ultimately, the reality is finding a simple and effective solution or library to ease the burden for these components.

00:22:44.120 For developers who need to accommodate natural language processing in time-related queries, tools like Chronic can come in handy. With this, developers can convert common estimations like 'third Wednesday in November at 3 PM' into readable time formats in Ruby.

00:23:34.930 Recurring events can be particularly difficult to manage. When planning a repeating event, the instinct may be to create records for each instance. However, this quickly becomes inefficient. It's often better to manage boundaries and populate singular records, reserving complex calculations for the underlying logic.

00:24:26.780 It's important to handle recurrence rules effectively. Tools exist, like IceCube in Ruby, that provide a framework for scheduling events efficiently. The complexity surrounding scheduling isn't just a technical hurdle; it presents a range of implications for developers.

00:25:19.860 To summarize everything discussed today: use standards—ISO 8601 whenever possible, and UTC for time. Simplicity and efficiency are often the best solutions when dealing with time, even as it relates to programming. Avoid excessive complexity; instead, embrace simple solutions that hold up against the challenges.

00:26:11.240 You should never build a calendar on your own; it's a recommendation I stand by. In conclusion, while time programming can feel daunting, remember that this is a problem that has been figured out over time.

00:26:58.580 Again, I appreciate your time today, and I want to thank you for being here and for your engagement during this conference and I'm glad we could all be part of this discussion.

RubyConf AU 2018