Yeah, you really dont want to be implementing a date/time library yourself. It is a far more complex problem than Fizzbuzz. There is so much nuance and easy to overlook details. Just determining whether or not a year is a leap year is about discuss complexity.
I wrote a friendlier abstraction over top Boost DateTime in C++ at a previous employer. Adding things like cross platform support of using the Olson database for historical timezone info, a friendlier interface (more akin to Python's datetime lib, which is probably the friendliest datetime lib Ive used across any language) and cross platform strptime. So, didn't do the heavy lifting myself, but rather supplied the timezone info.
There were so many subtle details. Like, what does it mean to add 1 day to a timestamp? Do you increment year/month/day as needed to be the next day? Or do you add 24 hours? This matters because if you increment the date only, you can end up with an invalid or ambiguous time. I also appreciate the author mentioning how many hours are there in a day. 23, 24 and 25 are most common for jurisdictions observing daylight saving time, but arbitrary shifts are possible. It depends on the jurisdiction. Take the US for example. It depends not just on the state, but sometimes even the county within a state. Some states dont observe DST (Arizona and Hawaii, maybe others). Parts of Indiana do, some don't (maybe this has changed).
Compound this with changes to when DST starts/ends. Its entirely political and can change on a whim. I know there are clocks that are still wrong 12 years later for 6 weeks of the year because of the 2007 US DST change, because of embedded rules for when to change.
Sorry for the rant. Spent over 18 months on that project, and I know there are bugs in there nobody bothered to fix after I left that company (fractional seconds handling in strptime I ported from NetBSD, I'm looking at you).
> Yeah, you really dont want to be implementing a date/time library yourself.
Someone should make a date/time "meta library" which iterates through all possible system time values while calling each extant language's date/time method at each iteration.
Then report the system time values for which there are discrepancies in the output.
I wrote a friendlier abstraction over top Boost DateTime in C++ at a previous employer. Adding things like cross platform support of using the Olson database for historical timezone info, a friendlier interface (more akin to Python's datetime lib, which is probably the friendliest datetime lib Ive used across any language) and cross platform strptime. So, didn't do the heavy lifting myself, but rather supplied the timezone info.
There were so many subtle details. Like, what does it mean to add 1 day to a timestamp? Do you increment year/month/day as needed to be the next day? Or do you add 24 hours? This matters because if you increment the date only, you can end up with an invalid or ambiguous time. I also appreciate the author mentioning how many hours are there in a day. 23, 24 and 25 are most common for jurisdictions observing daylight saving time, but arbitrary shifts are possible. It depends on the jurisdiction. Take the US for example. It depends not just on the state, but sometimes even the county within a state. Some states dont observe DST (Arizona and Hawaii, maybe others). Parts of Indiana do, some don't (maybe this has changed).
Compound this with changes to when DST starts/ends. Its entirely political and can change on a whim. I know there are clocks that are still wrong 12 years later for 6 weeks of the year because of the 2007 US DST change, because of embedded rules for when to change.
Sorry for the rant. Spent over 18 months on that project, and I know there are bugs in there nobody bothered to fix after I left that company (fractional seconds handling in strptime I ported from NetBSD, I'm looking at you).