Scheduling
UTC is Enough for Everybody, Right?
Edit
#timezones
#developer-experience-dx
#scheduling
Summarized using AI

UTC is Enough for Everybody, Right?

Zach Holman • May 25, 2018 • Sofia, Bulgaria

In the talk titled "UTC is Enough for Everybody, Right?" presented by Zach Holman at Balkan Ruby 2018, the complexities of time management in software development are explored, particularly focusing on the importance of understanding date and time systems. Holman, a developer with extensive experience from his time at GitHub and now the CEO of During, discusses how time, despite being a ubiquitous concept in programming, presents significant challenges when applied to the real world.

Key Points Discussed:

  • Understanding Time:

    • Time is a complex construct not only understood through physics but also through its social and political implications, especially for programmers dealing with global systems.

  • Historical Perspective:

    • The evolution of time measurement from early astronomical clocks to modern atomic clocks is outlined. This history illustrates how timekeeping has transitioned from vague concepts to precise standards.

  • The Time Zone Challenge:

    • The talk emphasizes the difficulties posed by time zones, which arose notably with the advent of the railroad industry. Time zones are not just one-hour increments, leading to complications in programming when different regions observe different rules.

  • Programming Challenges with Time:

    • Holman presents the idea that developers should primarily use Coordinated Universal Time (UTC) for storing timestamps to avoid complications. He stresses that UTC differs from Greenwich Mean Time (GMT) in several respects, particularly concerning daylight savings time.

  • User Interactions with Time Data:

    • There is a focus on the significance of presenting time data clearly to users through standardized formats (like ISO 8601) and allowing user customization in terms of date and time formatting preferences.

  • Examples Illustrating Misunderstandings About Time:

    • Anecdotes such as Samoa's decision to skip a day to synchronize with trading partners demonstrate the real-world implications of time measurement and coordination.
    • The controversial switch from the Julian to the Gregorian calendar in Russia exemplifies the tremendous confusion and logistical issues surrounding time discrepancies in global contexts.

Conclusions and Takeaways:

  • The overarching message is that time management is critical yet fraught with complexities in programming. Developers are urged to utilize UTC for uniformity and standardization.
  • Holman encourages programmers to be aware of historical and practical considerations when creating applications that involve time management. He concludes by suggesting that while building a calendar is an interesting challenge, it's advisable to approach it with caution, simplifying wherever possible to reduce potential confusion.

UTC is Enough for Everybody, Right?
Zach Holman • May 25, 2018 • Sofia, Bulgaria

Zach Holman is a developer living in San Francisco. He joined GitHub in 2010 as one of their first engineering hires, and helped build and grow their product and culture over five years. Currently he’s the founder and CEO of During, a new calendar to help you during your day. He also advises startups, including GitLab and Dockbit.

Balkan Ruby 2018

00:00:14.370 This is kind of amazing because all these people are sitting in the back, so it looks like a wall of human beings. It's terrifying. Anyway, it's about time.
00:00:20.500 It's like, about time it is to realize this.
00:00:27.640 I have so many puns this time. So let's start.
00:00:33.190 Time is hard. For example, you may have thought this talk started at ten in the morning. Turns out here we are later. Time is really hard.
00:00:48.070 Regardless of what language you pick or which cool framework you are excited about, everyone uses timestamps, dates... Time is a really good thing. But it shouldn't terrify you. And a lot of times, you'll see this online: 'Just use UTC.'
00:01:07.690 You can just pick some hair products and stuff, and we see this a lot. We say lots of blog posts and Stack Overflow threads and lots of other things about just using UTC. I'm going to tell you that it’s absolutely mostly true, but there's a lot more to it than just using UTC.
00:01:23.860 So, let me hold one up. All the social media things, as you can see in this photo, I represent time, and my cat represents how terrified it should be of me. I just love this photo because a Stripe employee actually shot this photo and they hate money, proving this photo did actually happen.
00:01:37.020 Once upon a time, I worked at GitHub. I was there for like five years. I started in 2010, and for a long time, I would joke with one of my co-workers, saying, 'If you look at a lot of scheduling and calendar stuff in the past, you just kept telling Zach: whatever you do, never build a calendar.'
00:01:51.619 I'm not very good at following directions, and I built a billion calendars. So, we've run into all the really terrible edge cases involved with scheduling time and recurring events, and all that sort of stuff. We get all the terrible situations, but everybody wants to solve some of these problems at some point in their career.
00:02:05.729 I have dealt with different aspects of scheduling and straight-up timestamps, and I think it’s important to start figuring out how to make our time code more resilient and better for our users. I've thought about this a lot this year, making notes on what I want to cover in this talk, and I want to share some of the things I've learned.
00:02:30.090 Today’s talk has a couple of different sections. First, we'll discuss: what is time? Then, we'll dive into a really deep philosophical viewpoint of why time is so hard. Finally, we'll look at the code in time.
00:02:42.900 The first question is: what is time? It’s a question as old as time itself. This is a good question because physicists are now even asking, does time actually exist? Is this an actual thing, or like, is this time a relevant concept in quantum mechanics?
00:03:08.940 I don't really understand that sort of stuff. If you probably want to deal with quantum mechanics in your real jobs, I hope there's a gym for it out there. Anyway, we exist, and I think that's all that matters. We can go from there.
00:03:31.020 When you first start out, let’s take a brief timeline of time and provide some background on the source of all this. So, back in 4000 BC, people using astronomical clocks started having a concept of like what a day is, which is comforting to know.
00:03:49.590 Asserting that days would have subdivisions; prior to this, we just stepped outside and were like, 'Yeah, it's daytime.'
00:04:02.790 It wasn't until the 14th century that we started having fixed-length hours. Previously, the length of an hour changed based on the season, depending on the growing season. Most of everything surrounding our knowledge of time stems from farmers.
00:04:19.020 Farmers are really important in this field, like you couldn't just walk down the street to the market and grow your own food like farmers.
00:04:31.470 In the 16th century, we started having minutes. We really cared about this at that point because the technology to measure time with minute accuracy was just starting to materialize. But now, like, our ancestors had to start getting everything right and making sure they were going to work on time.
00:04:50.140 In the 19th century, we had to start figuring out how to synchronize time with cities; that led to the development of time zones because of the railroad industry. So we decided: we need to standardize hotel and railroad time, which started the move towards cities being synchronized.
00:05:09.370 They used the telegraph to synchronize time over distances, which was kind of cool. Then, finally in 1967, we started getting atomic standards, which were really exciting.
00:05:17.140 If you have a lot of cesium in your backyard, go grab one. It tells you that a second is defined as 9,192,631,770 cycles of radiation; that's one second, which is pretty cool.
00:05:30.580 Atomic clocks are pretty exciting too. They lose about one second every 1.4 million years, so definitely reschedule all your meetings based on this time. And like that would be really interesting, we like optical clocks, which are like a hundred thousand times more accurate.
00:05:46.940 So, if you have one of these optical clocks now, we can trace them back to the Big Bang from 13.8 billion years ago and it would have lost about four seconds of accuracy to this point, which is kind of amazing.
00:06:02.810 But humans are sometimes not terrible. Then there’s the whole time zone problem. You know, all this is a very standard process for all programmers.
00:06:15.470 Everything I just mentioned revolves around one simple question: what time is it? Cool, you know, but there’s an implicit part of this question that we never asked for a while: it’s always been, 'What time is it here?'
00:06:34.430 We didn’t really need the location because I could just walk down the street and, by the end of the day or something, I could figure out what the time was, but at some point, we started asking the question, 'What time is it over there?' That question ruined everything.
00:06:55.450 Now we have to start figuring out, like, well I know my time zones, the teachings, the Earth's curvature, and that sort of stuff. It really made everything a hassle.
00:07:16.880 This is one of my favorite kinds of photos: the universal dial plate from 1854. All these little dials indicate different cities and what time they were having at that moment compared to everything else.
00:07:34.460 So if you’ve got programming now, it’s tricky to program in JavaScript like in 1850; it would be kind of a hard time. All right, we’re going to make time a concept. We are about to make a time table and figure out how many times it should be happening.
00:07:53.770 We have 24-hour and 24-minute time indices. That’s obviously not correct. We have left 39 last time I checked, and this is the first step in realizing why everything is terrible.
00:08:05.890 Start figuring out how time zones get added gradually; it hasn't been just politics or economics, but people wanting to screw over their neighbors or something like that.
00:08:24.190 But time is a little bit weird; and this time some data, that’s updated, doesn’t always align. Sometimes you are given the Olson database, which is a standardized database that has all these rules on who is moving and what they let say.
00:08:37.060 This is really tricky to figure this all out. A lot of things that revolve around that are important to keep in mind when working with time zones.
00:08:50.340 For example, time zones are not just one-hour increments; there are a lot of time zones that differ by 30 minutes, 45 minutes, etc. All of these complications come from the fact that we are trying to navigate a political problem.
00:09:02.950 Now, specifically, why is time really hard? I’m happy to say that humans have been really bad at understanding time for a long time. And it's not just that you as a civilization are pretty bad at managing all of this stuff.
00:09:10.089 It’s kind of like if you built a really nice hotel or a nice house, you’ve got all the stuff in there that you really want. However, I think you feel that you’re built on a really terrible foundation.
00:09:21.760 Let me give you a quick example: does everybody remember December 30, 2011? One voice was like, 'Yes!' Everyone else was going, 'What?'
00:09:37.740 This is interesting because Samoa went from December 29, 2011, to December 31, 2011. This happened because they looked up and saw that all of their trading partners, like China, Australia, Japan, and us, were really busy working on a Friday and they were just starting their weekend.
00:09:53.980 They thought this was really weird because they should really be on the same day as their trading partners. That’s like the important part of this entity: American Samoa is about a hundred kilometers away.
00:10:07.450 That’s the separation between linked dates on the planet. Schools, they thought up and said, 'Wow, all our trading partners are on a different time zone compared to where we are.'
00:10:20.230 Alright, so here we are with the last UTC; last time I checked, UTC was at plus 12 hours. So, this is 24 hours ahead of America. And you know, the northern hemisphere hospitality, which is totally true, because American Samoa doesn't observe Daylight Savings Time!
00:10:39.110 But this was an interesting point to have. Samoans once had Daylight Savings Time before, but they push it back a year because of a small earthquake that happened.
00:10:57.100 And I thought, this is really weird. You were probably thinking, 'I’ve heard this story before.' You probably have, because it’s a long time. It’s a timeline...
00:11:08.320 So let's go back to 1892, when the opposite happened. They looked up and said, 'Well, our trading partners in the United States said we should move the day backward.' So in 1892, they shifted back their clocks so they could be in sync with the U.S.
00:11:31.120 This is exciting because it’s the United States. They didn't have to do fireworks twice in a row before; it was exciting. And all this was very similar to the next dilemma where they decided to implement the new rules.
00:11:49.450 All this stuff helped illustrate a deep distrust of collaboration. Now, I am not advocating for avoiding change; that would be dumb! But it’s important to know that things don’t always sync up smoothly.
00:12:01.830 One other quick example to note: we had to transition to the Gregorian calendar. Previously, Russia was on the Julian calendar, and England's on Gregorian. This is important because the Olympics were taking place in London!
00:12:16.950 There were a number of days until the Russian shooting team arrived to London because they had a hard time understanding the time difference.
00:12:37.450 So, it's bloopers like this, but I think I feel worse that Russia didn't do this sooner, as their shooting team was supposed to arrive in time and missed out entirely.
00:12:55.900 So, time gets complicated; it’s tricky and hard. I have a huge long list of examples like these, but I just don’t have the time.
00:13:05.890 Let’s get into a big event: code in time. I’ll just take a stab at all this stuff at some point. It’s disparaging, but it’s exciting.
00:13:14.260 I want people like me who love this stuff to recognize the reality of it. So what happens when the circuit breaks?
00:13:36.450 I don't know if that means people should be concerned about time anymore, but keep that in mind as I discuss a bunch of little bits.
00:13:50.370 First off, let’s talk about how you store time in your systems. Use UTC! This is good advice for a reason; this keeps it simple.
00:14:03.650 There’s a reason why people keep saying this sort of stuff. UTC is a good universal coordinate and time. It’s like Commission has standard guidelines to establish terms for everything.
00:14:18.290 Now think about this from a whole different perspective. Understanding the rules of your time standard is critical to maintaining focus on this.
00:14:37.250 It’s also essential to note: UTC is not as similar to GMT. There are sometimes overlaps. In 2018, they would avoid applying daylight savings time.
00:14:50.510 As a general rule of thumb, the question to ask is: do you actually need to store time? I think that’s the first thing you should do.
00:15:11.800 Any time you set time for something—like an appointment—you should be very mindful of storing that data. Think about how it relates to people’s schedules.
00:15:40.500 In the future, there may be people who want to use that date as a floating event type of thing, and that’s where we end up in trouble sometimes.
00:16:04.130 But you want to store that as a timestamp so that when that thing actually happened, you can retroactively figure out if a daylight savings issue remap to that.
00:16:24.310 If there's still confusion, having something clear can help alleviate concerns later on.
00:16:36.659 Now, regarding how you translate this to users, you just need to understand how ridiculous this little sketch can seem.
00:16:53.320 It’s all about being consistent in using standardized formats.
00:17:00.400 The ISO 8601 is a format everyone should universally understand—this absolutely needs to be respected. A lot of developers should know how to deal with time this way.
00:17:23.860 But there’s another planning for implementing this is simply: take that leap to smooth out the dependencies between the complexities.
00:17:37.080 When you provide time, you ensure that your interface destroys any outside variables. So if necessary, send correctly formatted responses.
00:18:01.150 When formatting a string, you want to consider what connections people have to information. Also, try to format as clearly as possible.
00:18:17.560 User preferences matter—allow your users to set their own personal preferences in terms of how they want to format day and time.
00:18:43.090 If you don’t accommodate for that, then you risk ruining the experience. Look at this from the browser’s view.
00:19:03.680 JavaScript can be useful in formatting time. In some instances, you can work with a browser to properly manage how you can distinguish between items.
00:19:19.820 Additionally, it’s critical to stay on top of the latest web libraries as much as possible when working with these problems.
00:19:37.910 There are many edge cases that you want to avoid or sidestep entirely, which will unwittingly stack up quickly.
00:19:49.040 So, if you engage in really complicated calculations, or you can even pull up examples from libraries, continue finding newer libraries until you find the right one for you.
00:20:06.930 You’ll probably see a project that’s really interesting in relation to localization. They will allow you to format in a simpler way.
00:20:20.630 One thing I want to highlight is to aim for abstraction, as not everything has to be tied directly to a particular library.
00:20:37.220 When abstracting, keep in mind a level of accessibility; this involves formatting your strings accordingly to enhance readability.
00:20:54.350 For one, the next update could timestamp unpredictably, like if you leave the page open, it will display 'two minutes ago' or ''two weeks ago,' among other thoughtful updates.
00:21:03.430 Think about how that will affect the interactivity; it will be a big family point in your performance if you can improve on that.
00:21:17.710 There's lots of things done just from a decade ago that still have significant modern implications, especially in time how it can change things.
00:21:30.420 A recommendation I would give, though, is to consider the title attribute, which you may find helpful in giving your elements more functionality.
00:21:48.620 Utilizing data attributes will allow users to know when a message was sent and how long ago it is; this will also display the full UTC date with the actual timestamp.
00:22:05.710 To ensure you save time, utilize the HTML5 time element to provide certain timestamps. From there, you can easily add the more relatable descriptions, like, 'It was six minutes ago.'
00:22:23.360 This can be easily constructed across different platforms and maintained; obviously, if you can afford to use existing standards, do so.
00:22:38.490 You’re also able to have a 'date/time' attribute on that element, which obviously should rely on universal standards like ISO 8601.
00:22:51.550 You can utilize this if you're trying to support people building tools on top of your site, or spiders, for example, who are trying to find out how to convert these into more standard formats.
00:23:01.250 That type of strategy seems to go a long way in making sure the maintenance helps bring everything back into useful files.
00:23:22.050 Next thing to note involves inputting time. I don’t know if you’ve noticed, but for every single date input, there’s a challenge with most experiences.
00:23:40.410 Most experiences are not easy, and sometimes there’s nothing that seems particularly intuitive.
00:23:54.230 Most inputs can be frustrating; you don’t ever think there’s a good point. This can create quite the mess in assembling alternatives.
00:24:05.870 Then you have time selectors and everything, making it even worse; that’s where the mess starts piling up because one size does not fit all.
00:24:20.310 Whenever you’re building something out for a user-specific interface, keep in mind they're going to want their autonomy and experiences.
00:24:40.310 It’s terrible, but a valid suggestion is to just build out one that will work best for the one you choose and try to create something better for the next iteration.
00:25:02.370 Even in playing formats, it may be best advised to adhere to the original guidance, because you'll only improve as you get familiar with those interfaces.
00:25:16.520 Time is complicated; there's a lot to talk about. For example, there's an actual time logic based on structured expectations from how you use your time.
00:25:30.590 Next, let’s just revisit something we started a while back. Understanding time has its complications, but it is so crucial that we hone in on how the overall reliability will matter.
00:25:46.900 So remember to articulate the message around the standardized times, allowing simplicity for users to adapt.
00:26:00.810 Let’s share if you have any questions after this, but hopefully, this highlighted some of the underlying issues.
00:26:15.950 Remember, building a calendar is exciting but challenging. Avoid doing it if you can.
00:26:30.050 But if you must, hopefully you realize time isn’t as scary; all the time stuff is really weird only if people have conventions and norms delegated.
00:26:46.190 If you can avoid the complexities as much as possible and tackle simple things first, that’s usually the best approach.
00:27:02.430 So, in conclusion, if there are any questions or points you want to clarify, I will be around to discuss them.
Zach Holman
@holman
Explore all talks recorded at Balkan Ruby 2018
+12