Calendars have been like that since before computer programming existed. One of the early examples taught in high school programming classes is that of finding

Calendars have been like that since before computer programming existed. One of the early examples taught in high school programming classes is that of finding if a year is a leap year. Usually followed by noting how that change was introduced in most of Europe only in the late 16th century. A whole 10 days have gone missing in a bunch of countries, though everyone transitioned slightly differently. Many Eastern Orthodox countries only transitioned in 19th or 20th century, having 13 days disappear into the void. There are also leap seconds, so your seconds can go past 59 too. Calendars are a hard topic because they are tied to local standards so tightly. Let's not forget that not all cultures use the same "solar calendar" today either! The best approach is to decouple timestamping from locality (eg. only ever store UTC times), and embed locale data (like DST/timezone) only if needed (if you need to show time-of-creation local times for historical data). For everything else, you should interpret for display purposes, but the arithmetic and reasoning become much simpler. Julian dates (now's JD 2459146.6823) can help even more with that (similar to seconds-since-Unix-epoch we developers are used to, they count days-since-history-began in rational number form), but most time storage does not require stability going that far back, so just storing UTC times should work.