1628 1671 1798 1147 1900 1313 1101 1305 1220 1039 1536 1120 1211 1741 1578 1916 1133 1214 1358 1103 1498 1114 1998 1619 1500 1502 1719 1441 1533 1290 1511 1787 1704 1776 1598 1525 1007 1745 1060 1143 1201 1719 1426 1788 1548 1877 1394 1464 1081 1855 1482 1981 1476 1637 1510 1411 1217 1081 1383 1828 1777 1828 1801 1764 1253 1027 1624 1606 1714 1989 1379 1318 1330 1506 1086 1532 1403 1414 1931 1291 1327 1067 1686 1805 1927 1168 1867 1125 1730 1641 1612 1880 1383 1786 1630 1913 1314 1433 1655 Reasons why abolishing DST in the US will be worse for users and developers | PHPnews.io


Reasons why abolishing DST in the US will be worse for users and developers

Written by Evert Pot / Original link on Mar. 18, 2022

Daylight savings time is hated by many, and twice per year a discussion reignites to get rid of it. Lot of folks feel this is a great idea. This year this decision seems especially close in the US. If this law passes, it will probably also change where I live 🇨🇦.

No doubt there’s lots of benefits and advantages to this, I don’t want to dispute that. This is also not an endorsement against that change, but I do however want to bring light to at least one disadvantage:

The timezone change was for a lot of developers a twice-per-year reminder that we need to use timezone databases and libraries.

This is useful, because every year many countries change their timezone rules. This means that if you schedule something in the future, say.. 2pm 6 months from, you don’t know yet with absolute certainty what UTC timestamp this will be. This is especially important when scheduling between people in multiple timezones.

The right way to handle this is to store the intended local time + a location such as America/Toronto. EST is not enough, because it’s EDT half the year, and obviously neither is -0500. I grew up in the netherlands, and it was only when I got into programming I realized that our timezone is not +0100 all year round, unlike what we learned in school.

Timezones are relatively stable in North America, but the US also made a change in 2007, and it sounds like we may have another one in the future!

So this bi-annual time change was a great reminder to many developers that timezones are a thing, and you can’t just naively assume a UTC time + an offset is enough. Even more so for teams that are spread cross-continent because the DST change doesn’t fall on the same day. Currently I’m in the 3 weeks per year the time difference between me and my parents is 5 instead of 6 hours.

A lot of programming is (seems?) anglo-centric. A similar situation is that before Emoji became wide-spread it was way more common to see a lot more issues around encoding non-ascii characters 🤷 (billpg). Especially in languages that don’t have good native unicode support (looking at you PHP).

So if DST goes away in North America, I predict we’ll see more people assuming using the offset is enough, resulting in bugs related to:

It doesn’t help that one of the most common date formats (ISO 8601) uses an offset! (2022-03-18T17:05:30.996-0400). This is OKish for things that have already happened, but not good for anything in the future.

So when you hear developers excited about the US abolishing DST because it will make their (work) life simpler, remind them this is only true if you never intend your software to be used outside of North America, or when the entire rest of the world makes the same change and also freezes all timezone rules forever!


« Detect and Change Indentation With PHP - Make it Look Professional »