Daylight Saving Time. . . more complex to code for than you might think
Welcome to governmentally mandated jet lag :)
Well, not exactly but this topic has a special, and software-related, place in my heart.
The concept was invented by Benjamin Franklin in 1784.
A few years ago I was working as a consultant for an enterprise ISV who was building a hosted .Net application intended to be used by customers worldwide. Specifically, each user could choose their own "home" timezone and the intent was to always display dates and times from that perspective regardless of what computer they were using to view the data.
What I mean by this is: If your "home" timezone is based in Paris, your times are always shown in "Paris" time even if you're physically in Los Angeles. Some applications convert the dates on the client which would show you the times relative to timezone selected for the computer you are using. The problem with this is: If you are from Paris, and you are in Chicago looking at my computer and I am from Los Angeles, you might intuitively think that you are looking at "local" (aka Chicago) time but instead you would be looking at dates and times in my "local" (aka Los Angeles) time.
Some of our customers were working with the software on business transactions that involved many millions of dollars involving very critical timing so we decided this was unacceptable.
The .Net framework will allow you to translate back-and-forth from Coordinated Universal Time (abbreviated UTC and previously called GMT) but only relative to the timezone of the active operating system:
DateTime myTime = DateTime.Now;
utcTime = myTime.ToUniversalTime();
yourTime = utcTime.ToLocalTime();
// oops, I can't specify YOUR timezone!
Ok, so it's easy to convert from my "local" time to UTC but not easy to convert from UTC to an arbitrary "local" time since the ToLocalTime() method doesn't have an argument by which you can specify the local timezone you're interested in.
Now, you say what about changing the "local" timezone associated with the current application or thread?
Well, it turns out that you can't create an instance of the TimeZone object because the constructor is protected!
Therefore, it turns out the only timezone you use with the TimeZone class is the one defined by the one chosen when the operating system was installed.
So, how did I solve the problem?
I wrote a new ExtendedTimeZone class that inherited from System.TimeZone and had a constructor that took in a specification defining what timezone I wanted.
Note that this isn't exactly trivial, even within the US because some states don't subscribe to DST and one, Indiana, has different rules based on what county you live in!
This wasn't particularly hard but did lead to another interesting set of challenges: It turns out that the government of these United States isn't the only governmental agency involved in setting the rules. . .
The rules for Daylight Saving Time are different all over the world! In some countries, they are defined by specific dates that do not change each year. In some countries, the government changes the rules each year. And in some countries, they don't even follow their own rules! A co-worker from Israel told me that while the government sets the dates, the local rabbi's can arbitrarily decide that they want to make the switch earlier than the governmental date and so the whole country changes perhaps a week or two in advance and all the computers are wrong during that entire time.
In the end we got the data by subscribing to a quarterly update service that delivered the data in XML format that we could store on our server.
It all worked out OK but as I recall it took about 2 developer weeks to solve the problem and still requires a manual update of the XML file every 90 days.