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.
In the example you gave, wouldn’t the year be off by one when param2.month is 12?
I was transcribing it from memory and that exact problem cost me like two hours when I was writing it the first time. Well spotted, now write me a unit test for that case.
Using YearMonth.atEndOfMonth would have been the easier choice there, I think
holy shit, yeah it would have. tyvm, I’ll be putting in a PR first thing monday!
Would you mind trying to explain (ELI5 style) what you did before and why you are excited for this new method for those of us who dont understand code?
Unix epoch time in UTC, making sure that your local offset and drift are current at the time of conversion to UTC…
All dates and times shall be stored and manipulated in Unix time. Only convert to a readable format at the top of the UI, and forget trying to parse user inputs :P that’s just impossible