Sorry, you don't get a new March until you've finished the last one.
If you see anyone claiming that today is March 365th, congratulate them on fucking up their leap year math.
perl -e 'use Date::Parse; use POSIX; my @t = localtime; print strftime ("%a Mar ", @t) . int (1 + 0.5 + ((str2time (strftime ("%Y-%m-%d 3:00", @t)) - str2time ("2020-03-01 3:00")) /(60*60*24))) . strftime (" %X %Z 2020\n", @t);'
Mon Mar 366 09:14:24 PST 2020
Previously, previously, previously, previously, previously, previously, previously, previously, previously.
Date::Parse isn't part of core perl, so that might not work on some people's machines, this should work everywhere with at least Perl 5.0.0:
perl -MPOSIX -MTime::Local -e '@t = localtime; $d = int(1 + .5 + (timelocal(0,0,3,@t[3..5]) - timelocal(0,0,3,1,2,120))/(60*60*24)); print strftime "%a Mar $d %X %Z 2020n", @t'
Huh, that are the backslash near the end, trying again:
perl -e 'use Date::Parse; use POSIX; my @t = localtime; print strftime ("%a Mar ", @t) . int (1 + 0.5 + ((str2time (strftime ("%Y-%m-%d 3:00", @t)) - str2time ("2020-03-01 3:00")) /(60*60*24))) . strftime (" %X %Z 2020n", @t);'Okay, so I wasn't crazy, it did eat the backslash, trying one last time:
perl -MPOSIX -MTime::Local -e '@t = localtime; $d = int(1 + .5 + (timelocal(0,0,3,@t[3..5])-timelocal(0,0,3,1,2,120))/(60*60*24)); print strftime "%a Mar $d %X %Z 2020\n", @t'
It's not leap year math, it's just math. 1 + 365. We didn't cross a leap year day, it's just that there isn't a day 0. If Monday is the 1st and there are 7 days in a week, the next Monday is the 8th.
I admit to having screwed this up this morning. But I'm blaming long march and monday.
It depends on how they fucked it up, and which shifting sand they stuck their fenceposts in.
Why resort to str2time when you could use seconds since the epoch?
echo $(( ($(date --utc +%s) - $(date --utc -d "2020-03-01T15:00" +%s) ) / 86400 ))
365
1 day after March 1st is March 2nd.
365 days after March 1st is March 366th.
What's an example of someone doing it wrongly?
Well, you've introduced two unnecessary unportable dependencies, first on bash, second on the Linux-specific syntax of 'date'. And third but most importantly, some days have 23 hours and some have 25.
Please don't write any more time-related code.
I did not know software portability was a requirement; easily fixed if I know what I'm expected to target. I wanted to avoid string-to-date parsing and just use seconds-since-the-epoch... but using '/usr/bin/date -d' is just that. Damnit. Without string parsing I'll have to do something dumb like #define STARTOFPLAGUE 1583092800; which is not portable if not every machine has the same start-of-epoch. Portability is hard.
"I didn't know my code had to work", I just heard you say. Please don't write any more time-related code.
Probably time to post this again...
When I was young and full of hope and dreams, right at the beginning of this millenium, I wrote a date calculation routine in Perl. From it I quickly learned that there are lots of stuff that you should not even attempt to do: parsing HTML, do "simple" date arithmetic, write PDF, parse people's names, parse email, use SMTP, write your own database or custom file system, and oh so many more.
From reading this blog I also stay the fuck away from writing screensavers.
Probably time for this XKCD again
Python version: https://gist.github.com/amysoxcolo/d21efdc8dfb7aea00d8c31e746f6db29
So I was wondering; what's the criteria for when we can leave this double March timeline and go back to the the old one from before times? DNA Lounge re-opening festivities?
Pretty much that.