Under the section “Seconds since the epoch”, there is this trick:

secs=$((`TZ=GMT0 date \
+"((%Y-1600)*365+(%Y-1600)/4-(%Y-1600)/100+(%Y-1600)/400+1%j-1000-135140)\
*86400+(1%H-100)*3600+(1%M-100)*60+(1%S-100)"`))

This produces incorrect results when the current date falls in a leap year. For example, we are in a leap right now, so try this:

$ secs=$((`TZ=GMT0 date +"((%Y-1600)*365+(%Y-1600)/4-(%Y-1600)/100+(%Y-1600)/400+1%j-1000-135140)*86400+(1%H-100)*3600+(1%M-100)*60+(1%S-100)"`)); echo "$secs"; python3 -c "import time; print(int(time.time()))"
1588670315
1588583915

The result from the sh trick is off by 86400 seconds (24 hours). This issue occurs because the leap year calculation in the trick above is overcounting the number of days when we are in a leap year. For example, if the current date is 1972-01-01 00:00:00 UTC, the time that has elapsed since Unix epoch is exactly 730 days (63072000 seconds). This can be calculated in a straightforward manner: 365 x 2 = 730. However, the shell snippet above sees that 1972 is a leap year already and adds an additional day for it when it should not when we are still in 1972. That logic would work fine for 1973-01-01 00:00:00 UTC, i.e., when the year 1972 is completely over but not when we are still in 1972.

Having understood the cause of the issue, here is how we can fix the trick, so that it does not overcount a day for the leap year when we are still within the leap year:

secs=$((`TZ=GMT0 date \
+"((%Y-1600)*365+(%Y-1601)/4-(%Y-1601)/100+(%Y-1601)/400+1%j-1000-135140)\
*86400+(1%H-100)*3600+(1%M-100)*60+(1%S-100)"`))

Here is a test that shows that the issue is now fixed:

$ secs=$((`TZ=GMT0 date +"((%Y-1600)*365+(%Y-1601)/4-(%Y-1601)/100+(%Y-1601)/400+1%j-1000-135140)*86400+(1%H-100)*3600+(1%M-100)*60+(1%S-100)"`)); echo "$secs"; python3 -c "import time; print(int(time.time()))"
1588583977
1588583977

Having fixed that, I wonder if it is worth playing with fire like that. I have always used the much simpler awk-based trick like this:

secs=$(awk "BEGIN{srand(); print srand()}")

This produces the correct result. For example, see this output:

$ awk "BEGIN{srand(); print srand()}"; python3 -c "import time; print(int(time.time()))"
1588584040
1588584040

From the awk specification in POSIX.1-2008:

srand([expr])
Set the seed value for rand to expr or use the time of day if expr is omitted. The previous seed value shall be returned.

I don’t know if the above specification is sufficient enough to rely on awk’s srand() function to get the Unix epoch timestamp. I guess it depends on how an implementation interprets the phrase “the time of day”. On all Unix or Linux systems I have worked with so far, this is indeed interpreted as Unix epoch timestamp.

The following is not safe:

var=$(dirname "$f")

I…I had no idea! I was pretty sure I was safe because I rely so heavily on shellcheck.