Travis Colbert

I just had my mind blown!

I got a ping from a user that an automatic weekly report was being created with the wrong week-of-the-year number. Interesting... I hadn't noticed a problem with the week-of-the-year before.

(For simplicity let's just abbreviate week-of-the-year to WOTY from here on out)

In fact, the WOTY was generated inside of a BASH shell script on one line:

d=$(date +%YW%W)

The above one-liner sets the variable $d to {year}W{woty} like: 2019W40.

At first glance it seems that getting WOTY numbers is a no-brainer in BASH. There appears to be no way that this could be botched up. After all: there's no calculation going on here, no room for me to insert something broken into the code.

Alas! With all things programming there seems to always be room for bugs!

A close check in the date manpages shows:

     Week:
        W  Week of the year (00-52)

        V  Week of the year (01-53)
           If the week containing January 1 has four or
           more days in the new year, then it is considered week 1;
           otherwise, it is week 53 of the previous year, and the next week
           is week 1. Similar to ISO 8601 (but not 100% compliant.)

        U  Same as 'W'

So, I had chosen the zero-based WOTY number (0-52). It is probably fair to say that most calendars that bother to show WOTY numbers (like Google Calendar) are all one-based!

Mind blown!!

After collecting and re-assembling the pieces of my brain back into my skull I changed my seemingly no-brainer one-liner to this:

d=$(date +%YW%V)

Problem solved... for now.