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.
