To avoid being simply negative and cutting others’ efforts down, I will contrast the shambolic time and date situation in Java with the superior one in Python.<\/p>\n
The latter has two time and date packages. This is largely as a result of history. One, time<\/kbd>, came early on, and basically is a way to call the Posix time and date functions from Python. The other, datetime<\/kbd>, came later, and is geared to more advanced use cases.<\/p>\n I almost always just use time<\/kbd>, because as I said earlier, by far the most common uses for a time datatype are to create an instance of one and to print it. For that, the traditional time<\/kbd> library is more than sufficient.<\/p>\n But even datetime<\/kbd> is so much better designed than its Java counterpart. Instead of nine absolute time types, there are three (a calendar date, a time of day, and a date with a time). Instead of two relative types, there is just one (which, really, is all one needs). Instead of an elaborate set of classes devoted to formatting and outputting a time, there is just a strftime<\/kbd> method for each time object (and all the strftime<\/kbd>‘s use exactly the same format-specifying mini-language, which is mostly compatible with the one used in the Posix\/C world. The cognitive load of understanding it all is so much more reasonable.<\/p>\n As for the legacy class, its base time type is a Python floating point number. This is a value type, and as such avoids all the headaches associated with a mutable reference type. Its alternate time type is a Python tuple. Since tuples are immutable in Python, this also neatly avoids mutability headaches. And since standard, pre-existing data types are used, there is once more less cognitive load imposed on the programmer.<\/p>\n