How can you calculate the number of days since 1/1/1970? This is for updating the shadowLastChange attribute on OpenLDAP.
Is there a way to do this using the linux date command?
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
ring0 beat me by a few seconds, but the full command is:
echo $(($(date --utc --date "$1" +%s)/86400))
This goes by UTC time. Result:
root@hostname:~# echo $((`date --utc --date "$1" +%s`/86400)) 14984
A quick check with WolframAlpha shows that this is the correct value.
I needed to solve this as well, but I wanted to get the same value for the day# regardless of time of day. With approaches like those shown here, the value will change at midnight UTC instead of midnight local time. This probably seems like less of an issue in the EU or the U.S. East Coast, which are close enough to UTC that the day value won't change in the middle of the typical work day, but in, e.g., California, the day change would occur at 4pm PST, which might be inconvenient. I imagine Australians would be especially annoyed to have the day value change in late morning.
If we want to correct for that, we need to add the offset from UTC before dividing by secs/day. Fortunately, the Linux date command includes a %z format sequence which reports the offset from UTC. While the standard format (this result is for Denver time, MDT):
$ date +%z -0600
. . . isn't directly usable in a calculation, the right modifiers will yield what we want:
$ date +%-:::z -6
Put that together with the usual secs/hours/days conversions, and I believe the following should output the days since 1/1/1970, with 1/1/1970 itself being day zero, and the value incrementing at midnight local time:
echo $(( ( $(date +"%s + ( %-:::z * 3600)") ) / 86400 ))
This simple calculation will not work for time zones that are not offset from UTC by whole hours (e.g., India, TZ=Asia/Kolkata), since the "+5:30" produced by
date +%-:::z will produce an "invalid character in expression" error when used in the above statement.