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:
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.
ring0 beat me by a few seconds, but the full command is:
This goes by UTC time. Result:
A quick check with WolframAlpha shows that this is the correct value.
I think this is the simplest method:
The
datecommand can give you the number of seconds since1970-01-01 00:00:00 UTC.You can divide the result by
3600*24to get the number of days (UTC).E.g. in Bash
to display the number of days.
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):
. . . isn't directly usable in a calculation, the right modifiers will yield what we want:
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:
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 +%-:::zwill produce an "invalid character in expression" error when used in the above statement.