Alt text:
It's not just time zones and leap seconds. SI seconds on Earth are slower because of relativity, so there are time standards for space stuff (TCB, TGC) that use faster SI seconds than UTC/Unix time. T2 - T1 = [God doesn't know and the Devil isn't telling.]
I just spent two days debugging a reporting endpoint that takes in two MM-YYYY parameters and tries to pull info between the first day of the month for param1 and the last day of the month for param2 and ended up having to set my date boundaries as
LocalDate startDate = new LocalDate(1, param1.getMonth(), param2.getYear()); //pretty straightforward, right?
//bump month by one, account for rollover, set endDate to the first of that month, then subtract one day
int endMonth = param2.month == 12 ? param2.month + 1 : 1;
LocalDate endDate = new LocalDate(1, endMonth, param2.year).minusDays(1);
This is extraordinarily simply for humans to understand intuitively, but to code it requires accounting for a bunch of backward edge/corner case garbage. The answer, of course, is to train humans to think in Unix epoch time.
Unix epoch time in UTC, making sure that your local offset and drift are current at the time of conversion to UTC...
i don't even care if its wrong, I just want the code to be readable.
You should care if it's wrong.
at the resolution of clock drift in milliseconds when I'm running reports that are, at most, only specific to the day?
Clock drift? No. Time zones? Probably.
not really time zones either outside the edge case where a data point exists within delta of midnight so that the time zone drift would result in a date change
Time zones change. Relative times without time zones don't make sense.