Daylight Saving Time saves daylight, not time

Ryan Tan
4 min readMar 15, 2022
probably the most recognizable landmark on the west coast

Given that we just “spring forward” last sunday, I thought it to be the perfect time to reflect on this funny thing that happens twice a year (or if the recent Bill passes, never again). Nevertheless, I want to share about my learning experience.

When I started to have friends living on the US West Coast, I had to constantly figure out what time it was on their side, so that I could decide to ping them or not. And because we were messaging on Telegram, building a bot for this otherwise tedious task of mentally subtracting 15 hours from Singapore Time (GMT+8) seems a fairly simple endeavour.

The draft in my head went something like this:

Get the current time in Singapore Time
Subtract 15 hours from that.
Voila!

It all worked well for a couple of months. However, come November, the time the bot reported was 1 hour early and my friends reported that it was wrong. It was only then I realised the need to include Pacific Standard Time into my calculation.

To be honest, my approach moving forward from here wasted a lot of my time, hence this article to help others save time. If you want to skip ahead for a solution, just scroll all the way down.

Since I had the code to subtract 15 hours, I figured I would find out when DST will be in effect.

Get the current time in Singapore Timeif daylightSavingsInEffect:
Subtract 15 hours from that.
else:
Subtract 16 hours from that.
Voila!

However, as the following sections reveal, figuring out Daylight Savings Time was a problem. I tried 4 methods recommended from various sources and finally found the best solution.

1. Figure out DST using the Date() method

I just wanted to get something out quickly, so I tried the first method from StackOverflow. Since Javascript is able to return the Timezone Offset (from GMT) based on the time, we could store the standard offset (-8) and check if the current offset is GMT-7 (daylight savings) or GMT-8 (standard).

Now, I would like to point out that I have always lived in a country without DST so I assumed that it was something that followed astronomical events and would constantly change year after year. That’s why I went for this approach. It’s no excuse, yes, but I am just trying to explain what my blindspots are.

2. Figure out DST using the Google Maps API

This was an interesting one and I might have saw this on stackoverflow first. In an old version of Google Maps API, you could send a GET request for a location and get the timezone offset directly, for free. I think this solution could just be the dumbest one.

  • One, the API is not guaranteed to be up forever, as in this case the API has been moved to Google APIs which charges for usage. The story of left-pad also reminds me that we should try to limit our external dependencies.
  • Two, free apis usually come with a rate limit and indeed my bot stopped working after 5 calls.
  • Three, and this is the most important one, it is just an overkill as it requires an extra round trip call to an external endpoint.

3. Calculate using DST definition

After being limited by the Maps API, I had to find an alternative solution. And I was surprised that this wasn’t my first result. There was an elegant solution on Github Gist by Dan Alloway.

After reading his code, I found out how much of a roundabout I have went. My initial assumption about when DST occurs was totally wrong, it is the exact time every year.

4. Relying on IANA Timezone

Finally, I realized Javascript has an in-built parser all-along and this code from stackoverflow will show it. As my use case was purely for US, I decided that this piece of code is too verbose for me but it is definitely the way to go to account for DST in various countries (yeap, DST changes at different times for different people :/)

Insight on hindsight

The term “over-engineering” is definitely something that many of us have seen in software projects. However, I have grown to realize that it can be extended into other parts of my life, whether it is in products or decisions I make everyday. From this DST experience, I learnt to start questioning the “why” in the things I do and to uncover any blindspots early. There are thousands of solutions for the problems I face everyday, but every solution is for a different context, or “why”.

To you the reader:

I hope that I saved your time today in my article but do remember to always ask “why” so that you can save some daylight in your pursuit of an answer.

--

--