You may also be interesting to seeing the shenanigans from 2020 and 2016.

Last updated 2024-03-01 6:18 PM PST

Highest Impact

• Many petrol stations in New Zealand experienced problems with self-serve payment terminals, including Allied Petroleum, Gull, Z Energy, Waitomo, and BP - reported by Wired, The New Zealand Herald, and many others. The issue was reportedly related to Invenco payment solutions terminals. Invenco Group's CEO John Scott confirmed that indeed there had been a leap year glitch in their software. The bug has since been fixed, and an update was rolled out to their network of payment terminals worldwide.
• Payment terminals at ICA grocery and pharmacy stores across Sweden failed to process transactions on February 29th, according to various reports (1, 2). All types of payment cards were affected. Maria Elfvelin, media relations manager at ICA, stated that the problem was due to a leap day bug in their software. It has since been resolved.
• Sophos, a cybersecurity software vendor, issued an advisory that its products Sophos Endpoint, Sophos Server, and Sophos Home may experience an issue related to SSL certificates if the software is booted on February 29th. As a workaround, they originally suggested to manually disable the feature of their software that decrypts SSL/TLS (HTTPS) connections. Later, a policy update was applied that disabled the feature automatically.
  • At least one report of this indicated that the effect was a certificate validation error message on all outbound web requests. Their entire office was affected.
  • It's unclear if the feature has since been automatically turned back on or not.

Medium Impact

• Street lighting in Paris, France was inadvertently turned off at midnight at the start of February 29th, according to reporting by Le Parisien, a French daily newspaper. The operator, Cielis, told the reporter that the problem was linked to a programming fault related to the leap day. It took several hours for lighting to be manually restored.
• Fastrack FS1 smart watches appear to have problems displaying the date and time on February 29th. There have been several reports (1, 2, 3, 4, 5, 6, 7) describing or showing watches frozen at 11:59 PM on Feb 28, and a few other problems, likely related. Fastrack has acknowledged the issue and stated they are working on a fix.
  • Update: This issue appears to affect many different models of smart watches manufactured by Titan Watches. Their Twitter account also acknowledged the issue and stated they are working on a fix.
• Smart watches from Amazfit also had problems dealing with the leap day, either freezing or showing an incorrect date and time. Reports: 1, 2, 3
• Citrix issued a support article showing that the Citrix HDX HTML5 video redirection service crashes on February 29th. The suggested workaround is to set the computer's calendar date to March 1st, but this can cause other side effects. The issue also affects features related to a Microsoft Teams integration. According to another tweet, a private fix is now available but you must call support to get it.
• Coreboot, an open source firmware project, had a leap year bug that caused its realtime clock (RTC) date to be incorrect. The issue has been fixed and merged into the code base, but not before it could affect its downstream projects - including this bug in Dasharo, and this bug in Heads.
• Reportedly, computer systems that issue drivers licenses in parts of Japan had trouble operating on February 29th, according to reporting by The Japan News and BNN Breaking News.
• Details are scarce, but according to a post on Hacker News, an application related to creating marriage certificates had a bug where it subtracted a value from the year of an applicant's birth date to determine whether they were old enough to marry. The legal minimum age to get married in China is 20 for women and 22 for men. 2004-02-29 is a valid date, but 2002-02-29 is not.

Low Impact

• The financial services API suite Teller suffered a leap year bug in their certificate generation code, as reported by their CEO. Code sample included! The effect was that new accounts that signed up for Teller were not able to download a required certificate to use the service, until the bug was resolved.
• Phoenix Framework, a web development platform based on the Elixir programming language, had a problem related to certificate generation. When run on 2024-02-29, its phx.gen.cert task attempted to create a certificate with an invalid expiration date of 2025-02-29. A fix for the issue has been created, and should be included in the next release to prevent the problem from occurring again next leap year.
• Several different video games had reports of being unplayable on February 29th. The suggested workaround was to take the device offline and adjust its clock to a different date - or simply not play at all.
  • EA Sports WRC, which crashed on startup
  • Theatrhythm Final Fantasy, which presented the player with a black screen
  • Theatrhythm Final Bar Line, which was unable to connect to a remote server
  • Lilith's Throne, which crashed on startup with a message stating that February 29th, 2019 is not a valid date. (Note, the game itself is NSFW.)
• Best Buy, a leading electronics retailer, has an issue on their web site with the drop-down selections used for a credit card's expiration date. As reported in the comments section below, the credit card input form at did not support selecting February 2024 as an expiration date during the leap day. Since credit card expiration dates are valid-through dates, the form should not have disallowed a card expiring in February until March 1st. (Note: I was able to verify this independently.)
• The open source Akami Unified Log Streamer (ULS) has an open issue that displays a gap in the graph of daily activity where February 29th should be. The issue is also reported for the CLI of Akamai's Secure Internet Access (SIA) Enterprise product, previously known as Enterprise Threat Protector (ETP).
• The Apple Weather app has a very tiny leap year bug, as reported on Twitter. On February 29th, it reports the 30-day average precipitation is zero, regardless of location. Consequently, the daily amount is miscalculated as well. For example, in my area, it says the precipitation today has been 4.4", it then it reports that is also +4.4" above the 30 day average of 0". (Note: I was able to verify this independently.)
• The "On This Day" feature within the photos section of Microsoft OneDrive reportedly (1, 2) didn't show photos from February 29th of previous leap years, but rather it was stuck on February 28th.
• An open source home automation software component related to waste automation schedules encountered a leap year bug in their Python code.
• The open source COSMIA ACCESS-OM3 global ocean-sea ice-wave coupled model encountered a leap day bug, which appears to be related to another bug in the CMEPS component (Community Mediator for Earth Prediction Systems). The impact of this bug is likely constrained to the scientific data analysis usage that this model is designed for.
• A person posted to Hacker News stating that they were unable to purchase a YouTube Premium subscription, because the age validation logic thought they were under 18 since they were born on a leap day.
• A Redditor shared that the popular budgeting app YNAB ("You Need a Budget") had a bug with its feature for tracking recurring scheduled transactions that recur on the last day of a month. Reportedly, this month they all occurred on February 28th instead of February 29th.
• Reportedly (1, 2), Hesai LiDAR units had a bug related to the leap day, which has been addressed via firmware update. Shanghai-based Hesai was quick to note that the bug was limited to the older L4 units, and was not present in the newer AT128 model presently in use by passenger vehicles.
• Depending on how you ask it, OpenAI's ChatGPT 3.5 doesn't quite understand whether 2024-02-29 is a valid date or not. At least one user of the OpenAI API encounter failures in their own application due to this issue.
• As reported in the comments section below, Remind, the popular open source command-line scheduling tool has had an issue handling leap days since near its inception 28 years ago. It's author posted about the bug recently on their mailing list. The bug has been fixed and released today in the latest version 04.03.00.
• The Android app for BVG, the Berlin public transport company, issued a warning to its users that trips on February 29th appear under February 28th within the app. Reports: 1, 2
• The official mobile app for Irish Rail (public rail transit in Ireland) was not able to show any routes on February 29th. The issue was acknowledged, redirecting passengers to use their website instead.
• One person tweeted that Avianca airlines of Colombia printed tickets (or perhaps boarding passes) for February 29th were incorrectly given a March 1st date instead. They included a screenshot of an email they received from Avianca asking them to download their boarding pass again.
• The specific software is unclear, but here's an interesting find of a leap year bug in software at an eye doctor's office producing two different expiration dates within the same application, due to the leap day.

Unknown Impact

• A few different people mentioned that they experienced leap day bugs in their own code at various companies. Some included examples of their code, which I greatly appreciate! Reports: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
• The programming language Odin had a bug in its datetime_to_time function, which results in March 1st, 2024 incorrectly being coerced to February 29th, 2024. According to its maintainer in the comments below, the problem has been fixed in the latest commit, and will be included in the next monthly release dev-2024-03.
• The open source network operating system SONiC, a Linux Foundation project, appeared to be suffering build failures with its Azure Pipelines builds during a reboot test. (I'm unable to ascertain the full impact, but the bug appears to have been constrained to the build system, not the product itself.)

Unconfirmed / Coincidently Timed

• The City of Zürich, Switzerland, paid all of it's employees twice their regular amount for the month of February, as reported by the city itself and several news sources (1, 2, 3). Employees will have to pay the extra amount back. It was originally stated that the problem was due to a technical processing at Zürcher Kantonalbank (ZKB), but later was blamed on software used by Swisscom.
  • Note: I would move this to the "Highest Impact" section, however, it's still unclear if the issue was directly related to the leap day or just coincidentally timed. Note that the payroll date was February 26th, so the issue occurred well before leap day. It's plausible that the culprit was a leap day bug, but not confirmed. If anyone has more details about this one, please let me know!
• Cloudflare experienced an incident with billing-related services on February 29th, 2024, beginning around 02:00 UTC. It's currently unclear if this incident was caused by a leap year bug or just coincidently timed. While the scope of the incident is unclear, a person on Hacker News posted that they received an invoice with the date 1970-01-01 (the date of the Unix epoch) in the file name where it should have been 2024-02-29. However, the contents of the invoice appeared to be correct.
• The Innisfail Hospital in Cairns, Queensland, Australia experienced a total outage of its telephone systems on February 29th, as reported on Twitter. This might be related to a leap year bug, or could just be coincidentally timed.

Maybe Not a Bug

• Confusing, but perhaps by design, an event scheduled in Apple's Calendar app for February 29th that repeats "every year" actually only happens on leap years. It should be pointed out that Google Calendar does the same thing - it just uses a better phrasing: "annually on February 29th".

Got some that aren't in my list? Please let me know and I'll add them! See my About the Author page for contact info, or just comment below. Thanks!

Last updated 2020-05-25 11:32 PM PDT

Verified / Unresolved

Items in this section have been verified, and have not yet been resolved.

• The sports schedule in The Athletic's Android app shows the days of the week off by one. Reports: 1, 2
  The issue still remained as of March 9th, 2020. It is uncertain if it was repaired since then or not.
• The command line utility exa, a replacement for ls, shows file timestamps from Feb 29th incorrectly as March 1st. The issue was also reported last leap year, but has not yet been repaired.
• The PHP programming language skips over Feb 29th when using DateTime::createFromFormat with day of year placed before the year. Reported in 2012, and never fixed. Workaround: Put the year first. (This was in my list from last leap year also.)
• The photo sharing site 500px has problems editing photos taken on Feb 29th. The company acknowledged the issue on March 10th in a support thread, but has not yet reported a fix.

Verified / Fix Pending

Items in this section have been verified, and have a fix ready - pending release.

• The Python package timestring, which is used to parse strings into usable time objects, failed handling dates of February 29th. This led to an issue in HEPData, a site related to high-energy physic data. A fix for timestring is pending. HEPData is working around the problem for now.

Verified / Resolved

Items in this section had an impact on or near February 29th, were verified as actual bugs, and are now reported as resolved.

• Many people reported their cell phones were showing Feb 28th when it was actually Feb 29th, or some variation of showing the wrong date. Most appear to be using Boost phones on the Sprint network, and for at least one, Sprint confirmed the issue and stated they were working on it, while advising customers to set the time and date on their phone manually. Reports: 1, 2, 3, 4, 5, 6, 7, 8
  One of these people said things were working better on March 1st, and Sprint has stated the problem has been resolved.
• Users of Shadow, a gaming streaming service, encountered an "L-104 error" when trying to log in from Windows PCs, starting at 4 PM PST on 2/28 (which is midnight UTC on 2/29). The company originally asked their users to work around the bug by disabling time synchronization and set their clocks forward to March 1st. They issued an update about 9½ hours later correcting the problem, and then asked users to turn time synchronization back on. Full discussion on Reddit. (Excellent transparency here, but I don't recommend disabling time sync. That can lead to many other issues.)
• AppDaemon open source home automation software crashed on leap day due to trying to create a date of 3000-02-29. (The year 3000 is not a leap year.) The issue was resolved in version 4.0.2.
• Users of gohenry, a pocket money management app for children and parents, had an issue with scheduled allowances not being paid on Feb 29th. Reports: 1, 2, 3, 4, 5
  Go Henry stated the problem has been resolved on March 1st.
• The application Family Tree Analyzer displayed an error message with the "On This Day" functionality, when the day chosen was a leap day. The issue was resolved in version 7.6.1.1.
• Users of TPLink Energy Monitor noticed on Feb 29th that the entire month of February dropped off from daily reported values. One user also noted that the TP-Link Kasa application appeared to have a similar issue, and thus speculated it may be a device-side problem. The problem was reported to be resolved on March 2nd.
• The Python package Faker, used to generate fake data for testing purposes, failed when ran on Feb 29th. The problem has since been fixed.
• The synapse intelligent analysis package for Python had a problem handling the leap day. It has since been fixed.
• The C logging library Stumpless failed on leap day due to a botched conditional check. The problem has since been fixed.
• The open source Animal Shelter Manager software encountered a failure breaking animal records on Feb 29th. The problem has since been fixed.
• The third-party EDDiscovery add-on for the video game Elite Dangerous crashed on Feb 29th. The problem is now resolved.
• Tankathon, a website that provides mock sports draft simulations, reported having a leap day bug on Feb 29th. It was later reported fixed on the same day.
• The networking infrastructure software Krill, which lets organisations run delegated RPKI on their own systems, experienced a bug on Feb 29th related certificate generation. A representative from NLNet Labs reported the issue on March 2nd, and advised all Krill users restart their Krill instances and manually trigger republication. The issue was resolved on March 3rd.
• Players of the video game Dragon Ball Xenoverse 2, published by Bandai Namco Entertainment, encountered a crash on Feb 29th on the first character select screen. The game continued to crash even after leap day had passed. The issue was acknowledged in a support response email from one user. However, multiple inquires to Bandai Namco from other players went unanswered: 1, 2, 3
  Some players reported the PC version received an update on March 5th that appears to have fixed the problem. Reports: 1, 2
• Unit tests in the Perl TimeDate module failed on Feb 29th. (This was in my list from last leap year also.) The issue has now been resolved.
• On March 11th, The company behind the subscription management application Bobby App self-reported they were working on fixing a leap year bug. They later released version 3.0.1 to the Apple App Store, with a note in the changelog: "Fixed a bug with dates being off because of a leap year".
• The Python package aioftp, an ftp client/server for asyncio, had a problem related to the leap day with listing files. A fix has been made, and released in version 0.16.0.

Verified / Deferred

Items in this section had an impact on February 29th, but were either resolved through manual workarounds, or resolved themselves on March 1st without any specific fix or resolution reported. One assumes that the responsible party will take appropriate action before the next leap day in 2024, or has already taken such action, but to the best of my knowledge no confirmation of that has yet been provided.

• An automated streetlight system failed to operate correctly for the entire city of Aalborg, Denmark's fourth largest city. It took a few hours of darkness before the city's operations manager could figure out the problem and turn the lights on manually.
• Players of the video game Tropico 6 encountered a crash on the loading screen. The error message shows an Invalid Date error, with a date of 2019-02-29 (2019 is not a leap year). Reports: 1, 2, 3, 4, 5
  The game is reported working again, now that we're past leap day.
• The JakartaEE TCK Jenkins Jobs project reported many unit test failures when tests were run on Feb 28th and 29th.

Verified / Uncertain Cause

Items in this section have been verified to have occurred near the leap day, but may or may not have been caused by a leap year bug.

• National Australia Bank’s merchant and business banking facility, NAB Connect, had an outage that started around lunchtime on Feb 28th. It was reported resolved as of 9 PM local time on Feb 29th. It is unclear if this was directly related to a leap day bug or just coincidentally timed.
• A software glitch in the HR software for the Tamil Nadu, India government, delayed salaries for several government employees on Feb 29th. It is unclear if this was directly related to a leap day bug or just coincidentally timed.
• Hotel key cards and elevator access control in stopped working on Feb 29th at various hotels. This was confirmed via a letter from the Crowne Plaza hotel to their guests implicating a nationwide problem with Onity locks. It is unclear if this was directly related to a leap day bug or just coincidentally timed. Reports: 1, 2
• The online gaming service Origin, by Electronic Arts, experienced a massive global outage on Feb 29th. It continued into March 1st. It is unclear if this is directly related to a leap day bug or just coincidentally timed.

Verified / Not a Leap Year Bug

Items in this section have been verified to have occurred near the leap day, but were confirmed to not have been caused by a leap year bug.

• The stock trading platform Robinhood experienced multiple system-wide outages on March 2nd and March 3rd, that many people attributed to the leap year. Robinhood disagreed, stating:
  ​

  The outage was not caused by a failure to code for the leap year. We had instability in a part of our infrastructure that allows our systems to communicate with each other.

  Reportings: 1, 2, 3, 4, 5 (and many others)

  A Robinhood engineer also later confirmed that it was not leap year related.

• The certificate authority Let's Encrypt had an issue related to CAA Rechecking on Feb 29th. The bug was not related to leap year.

Unconfirmed

These items surfaced during my search or were brought to my attention by others, however I have not been able to confirm their validity. They may possibly not have happened at all.

• Several people reported that surgical air suction pumps in operating rooms at various hospitals, and other unspecified hospital software, went offline on Feb 29th.
• Some reported the date on their wristwatch skipped over the leap day, including a Timex Expedition watch, and a Casio watch. Another person gave a photo of various Casio watches including several that were working correctly, and an F91W-1 which was not (though that is by design since that model does not keep track of the year, per its documentation.).
• A user of the app for a Brazilian supermarket, Pão de Açúcar, highlighted a possible error with the app on Feb 29th.
• A person reported a possible bug with Patreon
• Some people reported probable leap year bugs with their Amazon purchase experiences. Reports: 1, 2, 3
• Several users of Google Maps have seen wildly incorrect routes for transit navigation on in King County, Washington, USA on Feb 29th. It's unclear if the issue is with Google Maps, or with the underlying data source. Reports: 1, 2
• A person reported that all of the Yealink T56 business desk phones displayed February calendar events for the wrong day.
• One person reported that LinkedIn listed the time they had been with their current employer incorrectly.
• A firearms dealer reported that the E4473 software released by the US Bureau of Alcohol, Tobacco, Firearms and Explosives is having trouble operating correctly today. This software is used by gun dealers to electronically complete Form 4473, registering firearms purchases.
• One person contacted me directly to share a screenshot of the Todoist mobile app, showing "Tomorrow Sat Feb 29", even though it was already Feb 29.
  Another person shared a problem with Todoist losing streak data on Feb 29th.
• A person contacted me directly and shared that the French post office system had a nation-wide bug on the 29th that prevented anybody from sending parcels. (Here is a tweet showing long lines at the post office.)
• A user of ElasticSearch's legacy client library for JavaScript opened an GitHub issue claiming problems querying data for Feb 29th.
• One person reported on March 1st that their Apple Watch was giving incorrect exercise data for February.
• A user of a Tandem Diabetes insulin pump with Control IQ software shows us a video, and reports incorrect IOB data during the transition between Feb 29th and March 1st.
• A person reported a problem with their Sensi smart thermostat not showing data for Feb 29th.
• A person shows us that their experience with the Chuck E. Cheese Sketch Book (photo booth) printed a date of March 1st when it was actually Feb 29th.
• A person reported a problem with the Turkish government's tax filing system, Defter-Beyan, which allegedly didn't allow February 29th as a valid date. It gave an error message that the declaration period has passed although it hadn't.
• A person reported that the date could not be set to Feb 29th 2020 on a Medisana BU 510 blood pressure monitor.
• A person reported that his transaction dates on PiggyVest, a Nigerian online savings and investing platform, were all displaying Mon Jan 19, 1970 when it was March 1st, 2020. Earlier, on Feb 28th, PiggyVest themselves quipped "February 80th 😫", but it is not clear if they were referring to their platform or not.
• One person reported that cash registers and rewards systems at Qdoba were down on Feb 29th. It's unclear if this was a just single location or if it is related to a leap year bug or just coincidentally timed.
• A person reported that the alarms on his Sonos smart speaker went off on Sunday March 1st, though they were only scheduled for Monday through Friday. It's unclear if this was related to a leap year bug or just coincidentally timed.
• A person reported that his Chase online banking app showed the same credit card payment twice - first on Feb 29th, then duplicated on March 1st.

Honorary Mention

• Timehop, which made my list from 2016 also, did indeed decide that it's not a bug but a feature! (and with a funny error message graphic!)
• Bantshire University (a parody account, not a real university), let us know that all IT systems are offline due to a complication with a date of March 0th. 😂
• Many developers mentioned that they encountered leap year bugs in their own code. Thanks for sharing! 1, 2, 3, 4, 5, 6, 7, 8
• Not a bug, but something to drink while you fix your bugs now, so they don't blow up next time around in 2024. 😊

Resources

You might also be interested in these other articles I've authored on the subject of leap year bugs:

• On the Life Cycle of a Leap Year Bug
• It’s 2020. Is your code ready for leap day?
• List of 2016 Leap Day Bugs
• Leap year bug - Wikipedia
• What are some examples of leap year bugs? - Stack Overflow

Please let me know (in comments below, or send me a DM on Twitter) if you have any corrections or additions. Thanks.

I've gathered quite a bit of knowledge in this area since then. Hunting down leap year bugs has actually been part of my full-time job for the last few months, believe it or not. When you work at a company like Microsoft, the sheer quantity of code written over the course of four years makes this a daunting task, but also a necessity.

Before we dive in to leap year, let's consider the life cycle of most bugs in software. They probably go something like this:

1. A software developer writes code for some product or service.
2. That code might go through review, testing, analysis, build, etc. Often, critical bugs are found during these phases and fixed before release. Sometimes not.
3. Eventually the code is released into production, or shipped to a customer.
4. The product or service is used. Critical bugs not found earlier are often exposed.
5. The user complains, files a support ticket, opens an issue, etc.
6. Sometimes code is rolled back to prior state, sometimes not.
7. Developer fixes the bug, and an updated release is deployed.

Sure, that's glossing over many areas, but it's roughly what happens. The interesting part is that usually the entire life cycle is on the order of days, weeks, or maybe months at most. Also normal bugs tend to happen one at a time, or a few with each release.

Leap year bugs are not like this. They have a very different life cycle.

Life cycle of a leap year bug:

1. A software developer writes code for some product or service.
2. Again the code is tested, analyzed, etc. But unless it's done on Feb 29th, there's a non-zero chance that a leap year bug goes unnoticed.
3. Eventually the code is released into production, or shipped to a customer.
4. The product or service is used. And everything works fine.
5. A long period of time passes. Maybe years.
6. Multiple other products and services are written and deployed over this time. Maybe taking a dependency on the first one, or importing its code. These services all work fine too.
7. Sometimes the original developer decides to move on to a new project, or a new company. Certainly nobody thinks there's anything wrong, because the products and services have been working quite well for years.
8. Feb 29th comes around. Stuff breaks all at once. Multiple service failures. Pagers go off. People panic. Nobody can find anyone who knows why. Eventually, someone figures it out and patches the code, gets things back up and running, but the damage has been done.
   OR
   Maybe nothing goes down at all. But somehow the numbers for this month don't look quite right. They're all off by a day and nobody knows why.
   OR
   Maybe nothing happens at all. The part of the product or service with the leap year bug wasn't exercised this time. So it sits for another four years, building even more confidence that everything is fine...

It's interesting to me that despite so many documented cases of leap year bugs, that this is not better understood by our industry. In an effort to fix that, I've started tracking types of leap year bugs in a Stack Overflow posting. If you don't know what leap year bugs look like, or if you have any to contribute, please take a look there. I've seeded it with two common cases, and I'll add more over time.

Let me know in comments here what you think! I can always blog more too. :)

How do I get the epoch time?

Or maybe:

I have an epoch time and I want to get the next day's epoch time.

Or even better:

I changed my epoch time to a different time zone and...

This is rubbish.  Stop.  Please, just stop and look at the words you are using.  Maybe you just have some large integer number and someone told you it was an "epoch time" so you think "epoch" is some name assigned to this sort of thing.  It's not.  Epoch is an English word.

According to Merriam-Webster:

epoch
noun | ep·och  \ˈe-pək, ˈe-ˌpäk, US also and British usually ˈē-ˌpäk\1a: an event or a time marked by an event that begins a new period or development
1b: a memorable event or date
2a: an extended period of time usually characterized by a distinctive development or by a memorable series of events
2b: a division of geologic time less than a period and greater than an age
3: an instant of time or a date selected as a point of reference (as in astronomy)

Note in particular that the word is a noun.  When one says "epoch time", they are using epoch as if it were an adjective.  It is not.

Of the above definitions, the third is the only one that applies in computing - in the same way that it does in astronomy.

An epoch is a reference point. It is the timestamp with the value 0.  It makes no sense to take a timestamp like 1507163237 and call it an epoch!

Wait, I thought epoch time was about the Unix epoch?

Well, you're getting a little closer to the truth now.  But please understand, while 1970-01-01T00:00:00Z is indeed the "Unix epoch", it is called this because that is the time we assign to 0 for a Unix timestamp.  So when you have a value like 1507163237, that is a Unix timestamp, not an epoch.

A few things you should know about Unix timestamps:

• Unix timestamps are always based on UTC (otherwise known as GMT).  It is illogical to think of a Unix timestamp as being in any particular time zone.
• Unix timestamps do not account for leap seconds.  They assume a perfect succession from one second to the next, without any leaps ever occurring.  This isn't the reality of course, so if you are expecting a series of Unix timestamps to be completely contiguous, you may be in for a surprise every so often.  One doesn't commonly need to concern themselves with this, however.
• Traditionally, Unix timestamps were defined in terms of whole seconds.  However, many modern programing languages (such as JavaScript and others) give values in terms of milliseconds.  So be certain you know which you are working with.  It is reasonable to say "a Unix timestamp in seconds", or "a Unix timestamp in milliseconds".  Some prefer the phrasing "milliseconds since the Unix epoch (without regard to leap seconds)".

So if the epoch is 0 and that happened in 1970, what's the big deal?

One only needs to point at the Wikipedia article on Notable epoch dates in computing.  Yes, there are multiple of them.  Depending on what you're doing, 0 might not be the Unix epoch, but some other epoch entirely.  Also note that that while the Unix epoch is always describing time on an absolute, universal time scale, some of the other epochs are not necessarily UTC based.

As an example, consider that "ticks" in a .NET DateTime object are based on a 0001-01-01T00:00:00.0000000 epoch.  One has to consider both "ticks" and "kind" to construct a DateTime, and "kind" is sometimes unspecified, meaning it cannot necessarily be mapped back to a point in UTC time.  O_o

Does it really matter?

Probably not.  I think people know what you mean when you say "epoch time".  I just think it's a bit silly.

I also recorded the presentation, and you can watch it on YouTube here (or below).

If you attended my talk - Thanks!  Please feel free to send any constructive feedback, positive or negative.  I am always looking to improve my speaking and teaching skills.

Cheers!

On Microsoft Windows desktop or server operating systems, you may find that the time will automatically change on the morning of Friday, July 8th.  This is because Microsoft issued KB3162835 in June which reflected the Egyptian government's previous decision to enact DST from July 8th through the end of October.  If you are applying automatic Windows updates, or getting the monthly builds of Windows 10, then you likely have this on your system already.  (An easy way to tell is to check if any of the newly added zones mentioned in the KB are present in the list of time zones on your system settings or control panel.)

Unfortunately, there simply isn't enough time between the date that the government changed their mind and the previous effective date for Microsoft to create, test, and distribute another update to retract this.  Microsoft is working on an update to release in the near future, but the availability date is uncertain at this time.  Meanwhile, many computers will reflect the time in Egypt inaccurately.

Microsoft's official guidance on this matter recommends two possible options:

• You can leave the time zone set for Egypt, and disable automatic daylight saving time via the Windows 10 settings page, or via the date and time control panel in previous versions of Windows.  This should be the preferred action for most desktop Windows users. The same thing can be done from the command line with:  

tzutil /s "Egypt Standard Time_dstoff"

• You can select a different time zone to set your computer to either (UTC+02:00) Harare, Pretoria, or (UTC+02:00) Tripoli. Neither of these use daylight saving time in 2016.  This is a good option for those on Windows Phone 10 devices, which do not have an option for disabling DST. Note that earlier versions of Windows Phone did not receive the June DST update, so they do not need to be changed at all.  

These are both great options, and are the only official recommendations from Microsoft.  However, they do not cover all possible uses of time zone information.  Other common uses include:

• Application servers running .NET applications that rely on the TimeZoneInfo class to provide accurate time for multiple time zones within a custom application.
• Exchange Servers that need to reflect times correctly in Outlook Web Access.
• Large organizations that need to correct time across many desktops and servers across their network.

For these scenarios, and many others, it makes more sense to correct the underlying Windows Registry data for the Egyptian time zone.  I have created a .REG file for this purpose, which you can download here.  Running this file on your system will correct the time zone information for Egypt Standard Time, removing the DST information for 2016, and canceling it for all future years as well.  DST information for 2015 and prior is left intact.  It is designed to be ran on Windows Vista and newer operating systems only.

Please note that this file is is an UNOFFICIAL and UNSUPPORTED patch, provided "AS-IS" by myself, Matt Johnson, independently of any activities of Microsoft.  While I do work for Microsoft, I do not work in the Windows group, and this is not a Microsoft product or supported solution.  Examine the registry file for yourself before making the decision on whether to apply it to your computers.  While I am confident that it will cancel DST for 2016 on your computers, I take no responsibility for any effects or side effects it may have.

If you're running a desktop operating system other than Windows, or any platform that uses the IANA time zone database, you can probably just update your tzdata distribution to 2016f, announced here.  However, for phones running iOS and Android, unfortunately you may have to wait for a system update to get the Egyptian time zone fixed.  Consider using the time zone of South Africa or Libya in the meantime.

If you have any questions about this, please ask in comments below.  I hope this helps a few people out there work around this issue until an official update can be provided.

The current time in Egypt is shown below.  If the time on your clock is showing an hour ahead, then you need to disable DST, choose a different time zone, or update your system.

Note: Some of the articles linked below may be in Arabic.  If, like me, you do not read Arabic, consider using the Google Translate Plugin within Chrome.  It works much better than using the Google Translate site directly, and better than other translator tools I have tried.

Originally, the Egyptian Cabinet announced (on April 29th, 2016) that daylight saving time was to take effect starting July 7th at 24:00 (which is the same as July 8th at 00:00), and that it was to go through "the end of October".  This was widely interpreted as meaning it would end on Friday October 28th at 00:00 - as in the past all DST changes in Egypt have occurred on Fridays.  This was agreed upon by all key parties in the time zone community, including IANA, Microsoft, and third party sites.

Both IANA and Microsoft released updates accordingly.  IANA with TZDB 2016e, and Microsoft with the June 2016 DST/TZ Update.  Between the two of these, it is likely that most computers and smartphones will advance their clocks by an hour on the morning of July 8th.  Well, at least those that have the updates installed will anyway.

However, two months later on June 27th, with less than two weeks before the previously announced effective date, the Egyptian Parliament voted overwhelmingly to abolish daylight saving time completely.

This has been followed up with many other news reports, including:

• The Prime Minister denouncing the Parliamentary vote, reportedly stating "daylight saving time, God willing, will be applied"
• A member of Parliament arguing that it "... is not the right of the Prime Minister [to] approve...", and that "... Parliament is the sole owner of the right in the legislation..."
• A member of the Cabinet providing a different start date entirely (July 5th) without any clear indication that the Cabinet had reached a different decision.  This may have been an error on his part, but the quote was widely republished on multiple news sites and social media, and thus some people are now planning to start DST on July 5th or July 6th (depending on whether you interpret midnight as the start of the day or the end of the day).
• Multiple arguments back and forth between the two branches about how DST is or isn't going to save them money, and a repeated argument about a $8M fine to IATA, that has not been well described.  Also, some proposals to keep DST in effect for 2016, but to abolish it thereafter.
• The state news agency reporting that DST will indeed start on July 5th, but stating that there is now no specific end-date in mind - and not acknowledging the Parliament's vote at all.
• See additional updates below.

And of course, the kicker is that even with all of these votes and announcements by the warring parties, there is not a single stitch of official published documentation to be found.  Not a single law passed, decree proclaimed, or even any acknowledgement by the State Information Service.  There are lots of other things being published - but somehow something as vital as a time change isn't worthy of documentation.

I previously wrote about the issues with short-notice time zone changes, and described what has happened in other countries in the past.  I also gave some advice to countries that are making time zone or daylight saving time changes - advice that Egypt certainly has not heard.  I'll also quote a member of the IANA TZ community who said it quite well:

If only it were made more clear that there very likely exists a point in time beyond which the costs incurred from having to deal with any particular observance or non-observance of DST are dwarfed by the costs incurred from uncertainty and duplication of effort in the lead-up to and in the wake of last-minute policy changes.- Tim Parenti
July 1, 2016

At this point, all any of us can really do is monitor the situation and hope that things work themselves out.  The best case would be for the start of DST to occur as it was originally announced and implemented in technology - on midnight between July 7th and July 8th.

Either cancelling DST for this year, or moving the start date up, will mean that the clocks on computers and smartphones will not agree.  The likelihood of economic impact would increase significantly.  Some people will miss important meetings.  Some people will miss their flights.  It will likely affect stock trading, traffic patterns, and other aspects of society that are time sensitive.  Some aspects of this are inevitable no matter what happens, as just like financial markets, uncertainty is never a good thing.

Whatever happens - next time around, please Egypt, announce the change far in advance, in an official published decree or law, and do not deviate from it at the last minute, or even entertain the idea of deviating from it.  The turmoil that uncertainty creates is more costly than any potential energy savings.

First Update

July 4th, 2016

On July 4th, just four days before DST would go into effect, the Egyptian Cabinet announced that they would accept the Parliament's decision to abolish DST.  While it's good to finally have consensus, the timing is pretty awful.  There's just not enough time to create, test, distribute, and install updates for computers and smart phones.  Thus it's quite likely that on July 8th, there will be considerable confusion about what time it is.

As a general recommendation, users in Egypt should temporarily disable daylight saving time on their computers and devices, if their devices support doing so.  Otherwise, they can choose a nearby UTC+2 time zone that does not use daylight saving time this year.  Libya or South Africa are reasonable choices.  Eventually, software vendors will distribute the appropriate updates and users can switch back to Egypt time after installing them.

Second Update

July 6th, 2016

• IANA has published TZDB 2016f in response to this change.  It should be available on most Linux distributions and Mac OSX soon.  iOS, Android, Java, Python, PHP and many other operating systems and programming platforms will also feed from this, but each has its own individual release cycle and process - so timing will vary.
• Microsoft has issued a blog post with interim guidance to follow until an update can be issued.
• Egypt Air issued a press release urging customers to check schedules carefully and arrive at the airport early.  (Note that even though pilots and air traffic controllers use UTC, most reservation systems use local times because they interact with consumers.  Even if the airlines update everything, times on printed tickets or third-party travel websites may be off.)
• Many international news agencies have picked up on the cancellation, including a good write-up by the Washington Post.  However, few people are yet talking about the problems that are sure to occur on Friday when many computers and clocks change to DST despite the government decision.
• The story has also been picked up by Reddit and Hacker News.

Third Update

July 6th, 2016

• I am providing a Windows Registry patch for those that need it.
• The current time in Egypt is shown below.  If the time on your clock is showing an hour ahead, then you need to disable DST, choose a different time zone, or update your system.  

Fourth Update

July 7th, 2016

As I'm writing this from the USA, it's July 7th still, but in Egypt it's already in the early hours of July 8th.  After the clocks struck midnight, several reports began coming in:

• Multiple news agencies reported that Apple iPhones switched to daylight time.
• Another user reported his Samsung Android phone also doing the same thing.
• One person tweeted that a Google search of "time in Cairo" incorrectly, and noted that timeanddate.com had it correct.  I was able to confirm this, and also checked Bing - which had the correct time - see images below:

Also, there were several reports about comments by a member of the TZ community.  Some reports were more accurate than others.  The comment in question was the well-established adage:

"Poor planning on your part does not constitute an emergency on mine!"
(widely attributed to Bob Carter)

In this case, the TZ member who aptly used this quote to describe the Egypt DST situation was absolutely correct, and I stand with him in this regard.  However the comment was misinterpreted by several Egyptian outlets as a refusal to help.  Other news reports were a bit more accurate. This one is probably the best I could find, and includes additional details.  Indeed, a fix was already in progress, and was released by IANA the very next day.

Fifth Update

July 8th, 2016

As expected, there are even more reports of time confusion today:

• Al-Ahram, the Egyptian state news agency, reports: Egyptians baffled as digital clocks change time despite abolishment of DST
• A news report describes Emirates Airlines flight 926 from Cairo to Dubai left an hour early, stranding 18 passengers.  (My guess is that the flight schedule was based on having an on-time arrival in Dubai.)
• Another person reported on Instagram that his flight on Royal Jordanian Airlines out of Egypt took off an hour early without him.
• The Egyptian Independent reports about ICANN.  It gets some parts right, but seems to think that ICANN operates servers that control time zones.  In reality, ICANN's IANA division simply hosts the tzdata files, and then it's up to the individual software vendors and service providers of the world to incorporate those files into their own offerings.
• At least one person mentioned on Twitter that his appointments in Google Calendar were not showing at the correct time.

Sixth Update

August 18th 2016

Microsoft has finally released a fix for Windows, in KB3177723.  Windows 10 users can simply install the latest OS build to receive the update.

Additional updates will follow as this event unfolds.

No, that's not the punchline to a joke.  It's actually quite a serious problem.  The biggest issue with time zones is not that they exist, nor that they have daylight saving time.  But rather, in that they often change in a haphazard manner.  Allow me to explain.

First, understand that from a global perspective, one might think that the time zones of the world should be managed by some relatively neutral international body, such as the ITU division of the United Nations, or perhaps the IAU.  However, each of the world's time zones are actually controlled from a local perspective.  Each individual nation has a sovereign right to decide the local time for the lands within their jurisdiction.  This includes both the offset from Universal Time, and the rules that govern daylight saving time, if they choose to use it.

This unto itself is not a problem, and absolutely I agree that countries should be able to do whatever they want with the clocks within their borders.  However, time and time again, we run into the same problem, which is simply that they are changed without enough notice.  All of the countries mentioned earlier have done this recently, along with many others.

It's crucial that when governments make changes to their time zones or daylight saving time rules, that they provide ample lead time for technology to catch up.  One has to consider the real work that people have to do to validate the change, create a data update, test the changes, and to publish and distribute the update.  Then you have to consider that individuals don't always update their systems instantly.  It's very common for a time zone update to be available for weeks or months before it is actually installed by the end user.

Turkey - A Case Study:

Let's look at Turkey as an example. In 2015, the government decided that it would be a good idea to delay the end of daylight saving time by two weeks to allow for more daylight hours at the polls during their election season.  They moved the end of DST date from October 25th to November 8th.

• The first word about this was from an unofficial news article on September 8th, about 6 weeks before the clocks were due to change.  However, this article wasn't noticed by the TZ community until around September 19th.  It's difficult to go off of news stories alone, as they are often wrong or fuzzy on the details.  A few words from a politician to a reporter is simply not good enough.
• On September 29th, a government news agency also reported the change.  It still wasn't fully official, as it had not come with any kind of decree or legislation.  But it was enough to convince some in the TZ community that it was real, and thus a change to the IANA TZ database was initiated, and then released a few days later on October 1st.
• The official announcement from the government finally came on October 4th, when it was published in the official gazette.  This is about three weeks official notice of the proposed change.
• Many technology vendors, including big players like Apple, Google, and Oracle, took the data from IANA and published it through their own channels.  As an example, Apple released it to iPhone and iPad devices with iOS 9.1 update, on October 21st, leaving only 3 days for users to install the update to prevent their clocks from changing on the wrong day.
• For Microsoft Windows, which follows a slightly different process and requires a higher degree of confirmation, an announcement was made on October 9th and an update was issued on October 20th.
• In some cases, the date was missed entirely, such as with pytz - the popular time zone library for the Python language, which published its version 2015.7 on October 26th.

So what was the result? Well, to quote the BBC:

Confused Turks are asking "what's the time?" after automatic clocks defied a government decision to defer a seasonal hour's change in the time.

Or as the IBT reported:

Millions of Turks woke up to a confusing morning on Sunday ... as smartphones, tablets, and computers had automatically updated in keeping with other countries in the Eastern European Time zone, even though Turkey delay setting clocks back an hour for the next two weeks.

You can imagine that this probably had exactly the opposite effect on voting than what was envisioned.  However, you think they would have known better, since almost the exact same thing happened the previous year!  As reported by the Independent Balkan News Agency in 2014:

An unbelievable confusion to 52.9 million Turkish voters was caused by the decision of the turkish government to postpone for a day the time shift applied all around the world, where the indicators are turned one hour forward. The reason for postponing the application of summer time according to the Erdogan government, was to facilitate the smooth conducting of the elections, but nobody predicted the "new technology" factor. All smart phones of the Turkish citizens changed the time automatically, resulting in thousands of voters going to the polls earlier having to wait for an hour to vote.

Similar problems were also caused to computers that had not downloaded a new version of the software. Problems also occurred in the luggage delivery system at Istanbul’s airport as the system automatically changed the time, ignoring the government’s plans and as a result the luggage were delivered to the passengers with great delay. There were also problems with many flights as passengers were confusing their departure time.

What about the rest of the world?

Not only did Turkey not learn from their own mistakes, but other countries around the world also have failed to learn from the experience and continue to have this problem.  Remember the list I rattled off earlier?  Let's take a closer look:

• Chile had been on "permanent DST" in 2015, but on March 13th, 2016, the government announced they would return to Standard time starting May 15th, 2016 (two months notice).
• Russia has 11 distinct time zone offsets, ranging from UTC+02 through UTC+12, with a complex history of changes in the boundaries between them. For 2016, six regions changed their time zones on March 27, 2016. Each of these regions had their own law placing the change into effect.  One was signed on December 30th (12 weeks notice), which is reasonable.  The others however were signed on either February 15th (6 weeks notice) or March 9th (2 weeks notice). Two other regions had pending legislation during this period, one of which didn't pass until April 5th, of which its effective date was stretched out until April 24th (3 weeks notice).  The other is still awaiting its final signature by the President, which is expected to occur in the next few days, and has an effective date of May 29th (4 weeks notice).  (Update: It was passed on April 26th.)
• Venezuela had been on UTC-4:30 since 2007, but the government recently decided that it would return to UTC-4 on May 1st, 2016.  The change was first announced on April 15th, then became official on April 18th when it was published in the country's Gazette (2 weeks notice).
• Azerbaijan canceled DST permanently in 2016.  It was scheduled to go into effect on March 27th, but the cancellation wasn't announced until March 17th (10 days notice).
• North Korea moved from UTC-9 to UTC-8:30 on August 15th, 2015.  The change was announced on August 7th.  (8 days notice)
• Haiti canceled DST for at least the 2016 calendar year.  It was scheduled to go into effect on March 13th, but on March 12th (just 1 day notice!) the government issued a press release canceling it.

Other Timing Issues

While all of the above changes come with a certain degree of surprise, there are other some parts of the world that simply don't make any advanced schedule at all for their daylight saving time rules.

Fiji is one such time zone.  It has had DST every year since 2009.  However, each year, the government issues an announcement stating what date it will begin and end.  It's slightly different each year, and it's unclear exactly when the government will reach their decisions, or what to do in the absence of an announcement.  It would be much simpler if they would just decide on a regular schedule, and only make announcements if there are deviations from that schedule.

Another such place is Morocco, where the schedule for the first start of DST and last end of DST are adequately defined, but every year since 2012 there has been a "DST suspension period", such that DST ends before the start of Ramadan, and is restored sometime after.  Not only does this mean that the clocks need to be changed four times in a single calendar year, but it also means that nobody is fully certain of when the middle two transitions will occur until the government makes an announcement.  Part of the reason for this is that the dates for Ramadan are based on the observed sighting of the new moon.  However, my personal opinion is that they should still fix the DST transitions to some schedule, even if it starts before Ramadan and ends sometime after.  The unpredictability of the dates makes it just too difficult to know what time it is in Morocco unless you are are actually there.  (By the way, Egypt used to do this as well, but only in 2010 and 2014.)

Recommendations to the World's Governments

First, I must emphasize that these are my personal recommendations.  I am not speaking on behalf of my government, my employer, nor the TZ community.  These recommendations are based on years of experience working with time zone data in computing, and the observation of real events.

If you're going to make changes to your time zone(s), whether they are for the standard time offset from UTC, or to the enactment or abolishment of daylight saving time, or to the dates and times that daylight saving time occurs then please do all of the following:

1. Give ample notice, preferably at least 6 months in advance of the change.  One year or more would be even better.
2. Provide that notice via an official government decree or passage of a law.  Publish the law, and make it available online on an official government web site.
3. Be sure to include the precise details of the change, including the date and the time of day that the change is to go into effect.  For example, state "the clocks will advance forward by 30 minutes on April 1st, 2017 at 01:00 local time".  Do not just say "The time will change in April".  Also, if the change only affects a particular region of your country, please specify the exact areas that are affected.
4. Notify your citizens and the world via press releases and the news media, but do not rely solely on this to communicate the change.  The official decree or law should trump any statement made to the press.
5. Send notification to the TZ community.  To do this, simply send an email to tz@iana.org, which is the address for the tz discussion list.  The email should contain a URL to the announcement published on an official government web site.
6. If the change is to be aborted, please give ample notice of that as well.

Following these guidelines will ensure that your change is observed by technology, including computers, cell phones, and other devices.

Recommendations to Software Developers

1. Don't try to invent your own time zones, or hard-code a list of time zones into your application.
2. Let the features of your platform or library perform time zone conversions.  Don't attempt to codify the rules on your own.
3. Don't rely solely on fixed offsets from UTC, nor make any assumptions about daylight saving time for a particular time zone.
4. Stay on top of time zone updates.  Be sure you know how to keep current, using the mechanisms of your platform or library.
5. Subscribe to the TZ Announcements mailing list, so you know when a new time zone update is available.
6. If you have knowledge of an upcoming time zone change in a particular area that deviates from the currently known information, or if you have other questions about time zones in computing, join the TZ Discussion mailing list.
7. Use timeanddate.com to validate any assumptions you have about the time zones for a particular region.  The accuracy of this particular site is well established, and  its owners participate in the TZ community.
8. For Windows, .NET, and other Microsoft products, watch the news feed on this site so you know when platform updates are available.  (Though you should prefer IANA time zones whenever possible, even if it means using a library to do so.)

If you're looking for information of how to avoid leap year bugs, or examples of disastrous leap year bugs from previous years, please read my article on the Microsoft Azure blog.

Please let me know if you have any corrections or additions.  Thanks.

Last updated 2019-04-03

Verified / Deferred

Items in this section had an impact on February 29th, but resolved themselves on March 1st without any specific fix or resolution reported.  One assumes that the vendor will take appropriate action before the 2020 leap day, or has already taken such action, but to the best of my knowledge no confirmation has yet been provided.

• Düsseldorf International Airport - Over 1,200 bags and suitcases didn't board planes on time, reportedly due to a leap day bug in the luggage conveyor system control software.
• Palo Alto firewalls - Error reportedly occurred while upgrading on 3k and 5k series devices. Reddit discussion. Other reportings: 1 2
• Veeam Backup & Replication - Installation and upgrades error due to certificate generation error. Additional reportings
• Blade Soho's iOS app couldn't make salon appointments on Feb 29 or Mar 1.

Verified / Resolved

Items in this section had an impact on February 29th, were verified as bugs, and are now resolved.

• CouchDB  Error fetching /favicon.ico.  Fixed in versions 1.7.0 and 2.0.0.
• Eldos SecureBlackbox security software for developers  TElHTTPSClient component crashes in its constructor on Feb 29, leading to HTTPS connectivity errors. Error was in the DateTimeAddYears function. Fixed in version 14.0.289.  Original report (link no longer working).  Archive of report.  Current Changelog (see version notes for 14.0.289)
• cPanel Bandwidth monitoring software  cPanel Bandwidth page failed to open on Feb 29. Fixed in v56
• Zotonic - the Erlang Web Framework and CMS  Error during static files request Fixed in version 0.13.8
• Ace Payroll (New Zealand)  Access Violation appears when launching program on Feb 29. Fixed in version 3.43C
• OSMC - Open Source Media Center  Setting a date in a scheduler failed on Feb 29. Fixed in version 2016.02-3
• eM Client email software  Fixed in version 6.0.24928.0
• Let's Encrypt Certbot - client for obtaining certificates  Fixed in version 0.4.1
• parsedatetime library for Python  Fixed in version 2.0
• OpenStack Dashboard (Horizon)  Fixed in version 8.0.2
• OpenStack Identity (Keystone)  Affected unit tests only Fixed in version 9.0.0.0b3
• Jekyll - Ruby based static site generator  Workaround provided in issue
• Rsyslog - Log file processing utility for Unix/Linux systems.  Fixed in version 8.17.0
• micro-strptime.js - date parsing library for JavaScript.  Fixed in version 0.2.3
• Money Manager EX - open source personal finance software. Multiple issues: 1 2 3 4 5 6. All reported fixed as of version 1.3.0

Verified / Resolved / Unknown Impact

Items in this section are also verified and resolved, but the vendor did not supply any supporting details as to what problems they actually had.

• VooFoo Studios - multiple online games
• Unshelved - online comics
• Cooking Mama - Japanese video game
• Plume Plotter - environmental app (UK)

Verified / Unresolved

• PHP - Missing Feb 29 when using DateTime::createFromFormat with day of year placed before the year. Reported in 2012, and never fixed.  Workaround: Put the year first.
• Perl TimeDate module - A unit test failed to run on Feb 29.  A patch was provided, but has not yet been applied.

Unconfirmed

These items surfaced during my search or were brought to my attention by others, however I have not been able to confirm their validity.  They may or may not have been caused by the leap day, or possibly not have happened at all.

• Apple iOS  (iPhone / iPad)  Possible bug in calendar app A few reports of alarms clock issues on Feb 29: 1 2 3 4 5  
• Apple Watch Calendar preview - A few reports of receiving a badge early: 1 2
• SunTran Alerts transportation app (Tucson, Arizona)  Reportedly, app shows no bus route stop times.  
• Qantas Airways mobile app  Reportedly, app didn't allow flight check in on February 29th.  
• Jeep Automobiles  Multiple reports of the dashboard clock resetting.   1 2 3 (one mentions a 2014 Jeep Laredo)
• SDG&E Utilities (San Diego, California)  Missing Feb 29 in an energy usage chart on their web site (used with smart meters).  
• Intuit Turbotax 2015  Allegedly not allowing Feb 29 as a date for eFiling signature.  
• United States Postal Service  Issues with redelivery scheduling: 1 2  
• MYZONE fitness tracker  Month total reset to zero on Feb 29 instead of Mar 1  
• United Airlines  Flight notification allegedly sent one day too early.  

Honorary Mention

• Python (in time.strptime function)  Not really a "bug", but just a commonly misused API. Evaluating future change as an enhancement.  
• HTC Sync Manager  Appointments from Jan 1 - Feb 29 were off by a day. Affected users for many weeks. Fixed in version 3.1.67.0, released in January (before leap day)  
• A "We I.D." digital sign  Mysteriously calculated the date of birth to be 21 years old as 1932. (2016 - 1932 = 84     84 / 4 = 21)  
• TimeHop iOS/Android app  Only showed tweets from four years ago, instead of the usual one year. It's not a bug, it's a feature!  

Looking to avoid leap year bugs next time around?   Check out my original post about leap year bugs.  And don't forget - December 31st 2016 is another important date!

Leap year bugs are covered in my Pluralsight course, Date and Time Fundamentals. If you enjoy this topic, please consider watching the video course!

"Meh," you say.  "My code is just fine.  We have unit tests."
"Oh really", I say.  "Do your tests properly mock the clock?  Do they test edge cases including February 29th and December 31st?  Have you tested any low-level C++ code you might have as well as the rest of your system?  Do you even know what a leap year bug looks like?"  Most often, blank stares.

There's a lot to cover here, so let's start with the most important things first.

• February 29th is not the only day affected by the leap year.  Another very important date is December 31st, because it is the 366th day of the year and many applications mistakenly hard-code a year as 365 days.
• Leap year bugs can be found anywhere, but are most dangerous in C / C++ code, where they can cause application crashes or buffer overflows (which are a security risk).
• Past leap years have included some high-impact, high-profile bugs, such as:  The 2012 Microsoft Azure outage - where miscalculation of a certificate expiration date caused service disruptions for up to 12 hours. The 2010 Sony PlayStation Network outage - caused by misidentification of 2010 as a leap year The 2008 bricking of all Microsoft Zune devices - caused by a logic error on December 31st. The 2008 Microsoft Exchange management bug, which prevented administrators from doing much of anything on February 29th. Lotus 1-2-3's miscalculation of year 1900, which still impacts Microsoft Excel today, over 30 years later!.  These are just the big ones that made the news.  I'm sure thousands more occurred with varying degrees of impact and noticeability.

The two most dangerous leap year bugs

#1: Adding or subtracting years in C / C++

In C / C++ code that uses the Win32 API, the SYSTEMTIME structure is a common representation of civil time.  It has distinct fields for each part of a date, separating the year, month, day values (and others).  It is very common to see the following code:

SYSTEMTIME st;       // declare a SYSTEMTIME variable
GetSystemTime(&st);  // set it to the current date and time
st.wYear++;          // increment it by one year

This code will succeed without error.  However, the risk is that if the code is called on February 29th, the resulting value will still be on February 29th, but in a non-leap year.  For example, 2016-02-29 + 1 year = 2017-02-29, which does not exist!

This value might be passed around quite a bit before it ultimately ends up as a parameter to another function, such as SystemTimeToFileTime, where it will cause the function to fail with a return value of zero.  Unfortunately, it is extremely common to find code that uses this method without checking the return value. This can lead to unpredictable results, such as leaving a FILETIME value in its uninitialized state.

• Always check the status result of Win32 functions, especially SystemTimeToFileTime.
• Correctly add a year to a SYSTEMTIME by checking the validity of the result and adjusting when necessary:

SYSTEMTIME st;       // declare a SYSTEMTIME variable
GetSystemTime(&st);  // set it to the current date and time
st.wYear++;          // increment it by one year

// check to see if it's a leap year
bool leap = st.wYear % 4 == 0 && (st.wYear % 100 != 0 || st.wYear % 400 == 0);

// If it's Feb 29th, but it's not a leap year, then move back to Feb 28th
st.wDay = st.wMonth == 2 && st.wDay == 29 && !leap ? 28 : st.wDay;

Note that a similar bug can also occur in standard C++ (non-Windows) code as well.  The tm struct is used instead of SYSTEMTIME, which has slightly different behavior.  Months are 0-11 instead of 1-12, so Februrary is month 1.  Instead of SystemTimeToFileTime, you might call _mkgmtime to produce a time_t structure.  The key difference though is that instead of it failing, when passing February 29th in a non-leap year, it will produce a value that represents March 1st.  Your application may be expecting February 28th, and if so it will need to adjust.

#2: Declaring an array of values for each day of the year

int items[365];
items[dayOfYear - 1] = x;

The above C code could just as easily be rewritten in C# or another language, or use a string or some other data type instead of an integer.  The key point is that we're declaring a fixed-size array to hold data, and assuming that there will be a location in the array for every day of the year.  The problem, of course, is that in a leap year, there will not be a place in the array for the 366th day, December 31st.

The effects of this vary considerably by language.  In C#, this will cause an IndexOutOfRangeException.  In C, unless the bounds checking compiler option is enabled, this will create a buffer overflow, the effects of which could be negligible, or considerable.  JavaScript developers have less to worry about in this regard, as a 366th element will be added automatically.

Data Filtering Issues

There are other effects of leap year bugs that can affect data anywhere from February 28th of the prior year, to March 1st of the following year.  Usually these are in data filtering, where a range query doesn't account for the extra day - either by assuming a year is always 365 days, or assuming February is always 28 days.  Consider a SQL statement such as:

SELECT AVG(Total) as AverageOrder, SUM(Total) as GrandTotal
FROM Orders WHERE OrderDate >= @startdate AND OrderDate < @enddate

This query is fine, but consider what happens if @enddate is set to today, and @startdate is set to today minus 365 days.  If the range happens to include the February 29th leap day, then it's not covering an entire year.  The start date is one day short, and thus the values are incorrect, assuming the intent was indeed to represent one year's worth of data.

When evaluating bugs like this one, ask yourself what the impact of the bug is.  In this case, where are these values displayed?  For example, if the average order amount is feeding a chart on a dashboard that gets updated every day, it might not be quite as important as when the total sales for the year is listed in a company's financial report such as an  SEC filing.  Of course, this assessment requires someone familiar with the application and it's usage; there is no one-size-fits-all rule to follow.

It may be tempting to solve this problem with an approach such as this:

TimeSpan oneYear = TimeSpan.FromDays(isLeapYear(endDate.Year) ? 366 : 365);
DateTime startDate = endDate - oneYear;

However, this is approach is flawed.  One cannot determine the number of days to add just by evaluating the year alone.  Consider that endDate could be 2016-01-01, and though 2016 is a leap year, there's only 365 days to subtract to reach 2015-01-01.  Instead, you have to consider whether or not the February 29th leap day is included in the range.  This leads to some fairly complex code if you try to do it by hand, especially when you consider covering multiple years instead of just one.

Ultimately, it comes down to the fact that TimeSpan in .NET (and similar types in other languages) is a representation of absolute time, and both "year" and "month" are units of civil time.  The absolute amount of time in a year or month is variable depending on which years or months you are describing.  (The same can actually be said for a "day" when you consider daylight saving time, though that's getting off-topic for this post.)

The correct solution for .NET is:

DateTime startDate = endDate.AddYears(-1);

The AddYears method correctly implements all of the necessary logic to determine how many days to move forward, or backwards in the case of a negative value.

Adding a year in JavaScript

JavaScript developers really should be using moment.js for this, where it's as simple as:

var m = moment();
m.add(1, 'years');

However, some folks still like to do things the hard way so you'll often see this:

var d = new Date();
d.setFullYear(d.getFullYear() + 1);

The problem here is one I mentioned earlier.  If today is February 29th of a leap year, then the resulting value will be March 1st.  That may or may not be acceptable to you.  Consider that for every other date, the result is in the same month as the original value.  Also consider that your application may be expecting an end-of-month date instead of a start-of-month date.

Here is a function you can use to correctly add years in JavaScript without requiring a full library:

function addYears(d, n) {
    var m = d.getMonth();
    d.setFullYear(d.getFullYear() + n);
    if (d.getMonth() !== m)
        d.setDate(d.getDate() - 1);
}

// example usage
var d = new Date();
addYears(d, 1);

This implementation adds the years, and then checks to see if the rollover to March occurred or not, and compensates if it did.  Again, do not try to implement this by figuring out exactly how many days to add - unless you really know what you're doing.

Other Common Mistakes

There are many other things developers get wrong related to the leap year, such as:

• Messing up the leap year algorithm.  It's not just every four years.  It's every four years as long as the year is not divisible by 100, unless it's divisible by 400.  1900 was not a leap year. 2000 was a leap year.  2100 will not be a leap year.
• Using an array of days in each month, where February has 28 days.  When using such an array, you must account for the 29th day in a leap year.  A better approach is to use a different array for leap years than for common years.  Or better yet - use the APIs you have (when available) instead of trying to do the math yourself.
• Branching the code for leap years, and then not testing all code paths.  For example, the code from the Zune bug has an IsleapYear(year) branch at the top, which clearly was never tested.
• Using separate year, month, and day values in without validating them.  For example, you may have a UI with separate drop-down controls to pick each component.  It's not enough to test that the day is valid within the month.  You also have to consider the year.
• Using the average length of a year, such as 365.25, or 365.2425 days in date math. While this may be scientifically accurate, it is never appropriate for actual manipulation of civil time.  At least, not if you care about accurate values.  It's fine if you only need an approximation, but the associated time-of-day will likely be off in the result.

How do I catch leap year bugs?

• Scrutinize your code carefully.  Search for anything time related, and go over it with a fine-toothed comb.
• Make sure you have lots of unit tests, and know how to "mock the clock" (described in the next section).
• Test year-round, not just before leap years.
• Validate all inputs, including configuration.
• Validate results and complete scenarios.  Have a failure strategy!

I'm often asked about two other approaches:

Static Code Analysis

It would be wonderful if there was just a set of tools you could run against your code that would point out where you had leap-year bugs.  Unfortunately, I don't know of any.  Simple string-search, or even regex search, can only get you so far.

Truly what is needed for .NET is a comprehensive set of Roslyn Analyzers that can catch common date/time bugs including leap year, time zone, daylight saving time, parsing, and more.  Unfortunately, I have not the time to create such analyzers myself.  Maybe I'll get to that at some point in the future, but it doesn't exist today.

It would also be nice to have similar tools for C++, JavaScript, and other languages.  Though I know of none.

Time Warp

Why not just move the clock forward and see what happens?  That might actually work for some systems, but there's a few problems with this idea.

• Your unit tests might still not catch everything.  You probably won't catch data filtering errors unless you actually look (manually) at every screen and report of your entire application.  This is error prone for sure.
• You might develop a false sense of security, believing everything to be ok.  Only when your customers call complaining on February 29th or March 1st will you realize how wrong you were.
• Many systems have to authenticate with domain servers, or use other authentication schemes that are time sensitive.  Recognize that the Kerberos protocol has strict time sync requirements, with a default tolerance of 5 minutes.  Also consider that SSL certificates, code signing certificates, and other security-related things are clock dependent and will fail if you try to lie about what time it really is.

So, in general, I recommend against this approach.

Mock The Clock

How do you test code that behaves differently on different dates?  Mock the clock!

This is a common pattern found in many reliable systems.  The key point is that the system clock - you know, the thing that tells you what time it is - should not be used haphazardly.  Application logic should never make a direct call to DateTime.Now or DateTime.UtcNow or new Date() or GetSystemTime or whatever the equivalent is in your language to get the current date and time.

Instead, you should treat the clock as a service (in the DDD sense), and like any service, you should be able to mock it.

For example, in .NET, instead of directly calling DateTimeOffset.UtcNow (or similar APIs) from application logic:

• Create an interface IClock with a method GetCurrentTime that returns a DateTimeOffset.
• Create a SystemClock class that implements from IClock, where GetCurrentTime calls DateTimeOffset.UtcNow.
• Create a FakeClock class that implements IClock, which accepts a fixed value as a constructor parameter and where GetCurrentTime simply returns the fixed value.
• In your application logic, only depend on the IClock interface.  Typically this is constructor injected.
• Use a FakeClock during testing, and wire up a SystemClock at runtime.

This may sound like a lot of work, but once you go through the motions you'll see where it has advantages.  This is truly the only way to ensure all of your code is tested when the current date and time are dependencies.

I intentionally did not provide code for this here, as the pattern should be the same for many different languages.  Also, there's already a really great implementation of this in Noda Time, which comes with IClock and SystemClock in the main assembly, and FakeClock in the NodaTime.Testing assembly.  You'd do well to use Noda Time for this, and many other reasons.

Conclusion

Leap year is here.  It's not Y2K, or Y2038, but it is something we have to contend with on a regular basis.  How much code did you write over the last four years?  Are you sure it's all up to par?  Take the time now to test and scan through your code.  You will probably find a few things you didn't realize were lurking in the shadows.

I'll also be giving a talk on this subject at CodeMash in Ohio, Jan 7th 2016. If you're going, stop by and say hello!

         "Yeah Buddy,"

"Guess what time it is?"

         "... I ... Don't ... Know !!!"

"It's time to... uh..  to.. Hey, what the hell time is it anyway?!!  What's going on!"

         "I used to know, or I used to think I knew.  I just don't know any more!"

"I don't know either."

MISSION ACCOMPLISHED!

.NET Rocks, #1230: Date and Time with Matt Johnson

Many thanks to the .NET Developers Association here in Washington for putting on this event.  I hope to come back and speak again next year!

If you're interested in time, especially with .NET, I hope you will listen!

Check it out in show #485.

var d1 = new Date("2015/06/17");
var d2 = new Date("2015-06-17");

How about these?

var d1 = new Date("2015/06/17 00:00:00");
var d2 = new Date("2015-06-17 00:00:00");

Or these?

var d1 = new Date("2015/06/17 00:00:00");
var d2 = new Date("2015-06-17T00:00:00");

Still unsure?  How about now?

var d1 = new Date("2015/06/17 00:00:00");
var d2 = new Date("2015-06-17T00:00:00Z");

Ah, that's it!  In all of the above examples, d2 is parsed as UTC, while d1 is parsed as local time.  This occurs because all of the d2 strings are valid under ISO 8601.

There's a problem though.  ISO 8601 specifies that time without a Z, and without an offset (such as -08:00) should be treated as local time. In the above examples, all but the last one were without offset - so why were they parsed as UTC?

Well, in the EcmaScript specification (up to and including the current ES5.1), there is part of the spec that states (in section 15.9.1.15)

... The value of an absent time zone offset is "Z".

That explains the current deviation from ISO 8601, and why folks have trouble understanding why they get the "wrong" date when they do something like this (screenshot from Chrome):

So, to make this align with the ISO 8601 spec, this line was changed in the ES6 specification (in section 20.3.1.16).  It now says:

... If the time zone offset is absent, the date-time is interpreted as a local time.

That's great for compliance and spec alignment.  But it's a serious issue for backward compatibility.  Any code that expects the Date constructor to parse a date as UTC will need to be updated.

To maintain compatibility as ES6 is adopted, it's important to not rely on this bit of functionality.  Instead, if you to parse as UTC then you should explicitly add the Z.

var d = new Date("2015-06-17Z");

This will parse as UTC both today with ES5, and tomorrow with ES6.

If you need to parse as local time, you could consider using the slashes, like I showed as d1 - but this isn't guaranteed to work in all browsers.  (I've been told that it doesn't work in some versions of Safari.)

A better approach, for both local and UTC, is to use Moment.js.

var m1 = moment("2015-06-17");      // local time
var m2 = moment.utc("2015-06-17");  // UTC

Both m1 and m2 are moment objects, so if you need a Date, then call .toDate().  Or if you need a string, then use .format() or .format("MM/DD/YYYY"), or any of the other functions offered by the library.

Regardless of whether you use a library or manually add a Z, you should prepare for this change today so that you won't be bit by this as ES6 starts making its way into browsers.

Update

This matter was also discussed in ECMAScript tc39 issue #87, and then the spec was augmented in PR #138.  The net effect is that date-time forms such as "2015-11-04T00:00:00" are indeed interpreted as local time, per the ES6 spec and ISO8601, but the date-only forms such as "2015-11-04" are still interpreted as UTC.  The first part is great, but the second part is really confusing and doesn't match ISO8601.  In my opinion, all browsers should treat both forms as local.  They should only be treated as UTC if they are followed with Z or +00:00.

Currently, all modern browsers except Chrome will treat the date-time form as local, and all modern browsers treat the date-only form as UTC.

This material is also covered in my Pluralsight course, Date and Time Fundamentals. If you enjoy this topic, please consider watching the video course!