I am trying to calculate the time elapsed since the log file was last updated.
I guess following commands will be used
lastUpdate=$(date -r myLogFile.log)
now=$(date)
How can I subtract them and get result for number of seconds elapsed?
datekshshellshell-script
I am trying to calculate the time elapsed since the log file was last updated.
I guess following commands will be used
lastUpdate=$(date -r myLogFile.log)
now=$(date)
How can I subtract them and get result for number of seconds elapsed?
I didn't find a simple solution to my question, so I've written a small Bash script to solve it. You need to download the leap seconds file given in the link below and put it with the script or change the path to it. I didn't write utc2unix.sh
yet, but it's very easy to adapt. Do not hesitate to comment/give suggestions...
unix2utc.sh:
#!/bin/bash
# Convert a Unix timestamp to the real number of seconds
# elapsed since the epoch.
# Note: this script only manage additional leap seconds
# Download leap-seconds.list from
# https://github.com/eggert/tz/blob/master/leap-seconds.list
# Get current timestamp if nothing is given as first param
if [ -z $1 ]; then
posix_time=$(date --utc +%s)
else
posix_time=$1
fi
# Get the time at which leap seconds were added
seconds_list=$(grep -v "^#" leap-seconds.list | cut -f 1 -d ' ')
# Find the last leap second (see the content of leap-seconds.list)
# 2208988800 seconds between 01-01-1900 and 01-01-1970:
leap_seconds=$(echo $seconds_list | \
awk -v posix_time="$posix_time" \
'{for (i=NF;i>0;i--)
if (($i-2208988800) < posix_time) {
print i-1; exit
}
} END {if (($(i+1)-2208988800) == posix_time)
print "Warning: POSIX time ambiguity:",
posix_time,
"matches 2 values in UTC time!",
"The smallest value is given." | "cat 1>&2"
}')
# echo $leap_seconds
# Add the leap seconds to the timestamp
seconds_since_epoch=$(($posix_time + $leap_seconds))
echo $seconds_since_epoch
Just some tests:
date --utc +%s && ./unix2utc.sh
-> today and at least until June 2015 the difference is 25 sec../unix2utc.sh 78796799
-> 78796799
./unix2utc.sh 78796801
-> 78796802
./unix2utc.sh 78796800
-> 78796800
+ on stderr: Warning: POSIX time ambiguity: 78796800 matches 2 consecutive values in UTC time! Only the smallest value is given.
That last example should have clarified things for you: timezones.
$ TZ=UTC date -d "2019-01-19T05:00:00Z - 2 hours" +%Y-%m-%d_%H:%M:%S
2019-01-19_03:00:00
$ TZ=Asia/Colombo date -d "2019-01-19T05:00:00Z - 2 hours" +%Y-%m-%d_%H:%M:%S
2019-01-19_08:30:00
As the output clearly varies by the timezone, I'd suspect some non-obvious default taken for a time string without a timezone specified. Testing a couple of values, it seems to be UTC-05:00, though I'm not sure what that is.
$ TZ=UTC date -d "2019-01-19T05:00:00 - 2 hours" +%Y-%m-%d_%H:%M:%S%Z
2019-01-19_08:00:00UTC
$ TZ=UTC date -d "2019-01-19T05:00:00Z - 2 hours" +%Y-%m-%d_%H:%M:%S%Z
2019-01-19_03:00:00UTC
$ TZ=UTC date -d "2019-01-19T05:00:00" +%Y-%m-%d_%H:%M:%S%Z
2019-01-19_05:00:00UTC
It's only used when performing date arithmetic.
It seems the issue here is that - 2 hours
is not taken as arithmetic, but as a timezone specifier:
# TZ=UTC date -d "2019-01-19T05:00:00 - 2 hours" +%Y-%m-%d_%H:%M:%S%Z --debug
date: parsed datetime part: (Y-M-D) 2019-01-19 05:00:00 UTC-02
date: parsed relative part: +1 hour(s)
date: input timezone: parsed date/time string (-02)
date: using specified time as starting value: '05:00:00'
date: starting date/time: '(Y-M-D) 2019-01-19 05:00:00 TZ=-02'
date: '(Y-M-D) 2019-01-19 05:00:00 TZ=-02' = 1547881200 epoch-seconds
date: after time adjustment (+1 hours, +0 minutes, +0 seconds, +0 ns),
date: new time = 1547884800 epoch-seconds
date: timezone: TZ="UTC" environment value
date: final: 1547884800.000000000 (epoch-seconds)
date: final: (Y-M-D) 2019-01-19 08:00:00 (UTC)
date: final: (Y-M-D) 2019-01-19 08:00:00 (UTC+00)
2019-01-19_08:00:00UTC
So, not only is no arithmetic being done, there seems to be a daylight savings 1 hour adjustment on the time, leading to a somewhat nonsensical time for us.
This also holds for addition:
# TZ=UTC date -d "2019-01-19T05:00:00 + 5:30 hours" +%Y-%m-%d_%H:%M:%S%Z --debug
date: parsed datetime part: (Y-M-D) 2019-01-19 05:00:00 UTC+05:30
date: parsed relative part: +1 hour(s)
date: input timezone: parsed date/time string (+05:30)
date: using specified time as starting value: '05:00:00'
date: starting date/time: '(Y-M-D) 2019-01-19 05:00:00 TZ=+05:30'
date: '(Y-M-D) 2019-01-19 05:00:00 TZ=+05:30' = 1547854200 epoch-seconds
date: after time adjustment (+1 hours, +0 minutes, +0 seconds, +0 ns),
date: new time = 1547857800 epoch-seconds
date: timezone: TZ="UTC" environment value
date: final: 1547857800.000000000 (epoch-seconds)
date: final: (Y-M-D) 2019-01-19 00:30:00 (UTC)
date: final: (Y-M-D) 2019-01-19 00:30:00 (UTC+00)
2019-01-19_00:30:00UTC
Debugging a bit more, the parsing seems to be: 2019-01-19T05:00:00 - 2
(-2
being the timezone), and hours
(= 1 hour), with an implied addition. It becomes easier to see if you use minutes instead:
# TZ=UTC date -d "2019-01-19T05:00:00 - 2 minutes" +%Y-%m-%d_%H:%M:%S%Z --debug
date: parsed datetime part: (Y-M-D) 2019-01-19 05:00:00 UTC-02
date: parsed relative part: +1 minutes
date: input timezone: parsed date/time string (-02)
date: using specified time as starting value: '05:00:00'
date: starting date/time: '(Y-M-D) 2019-01-19 05:00:00 TZ=-02'
date: '(Y-M-D) 2019-01-19 05:00:00 TZ=-02' = 1547881200 epoch-seconds
date: after time adjustment (+0 hours, +1 minutes, +0 seconds, +0 ns),
date: new time = 1547881260 epoch-seconds
date: timezone: TZ="UTC" environment value
date: final: 1547881260.000000000 (epoch-seconds)
date: final: (Y-M-D) 2019-01-19 07:01:00 (UTC)
date: final: (Y-M-D) 2019-01-19 07:01:00 (UTC+00)
2019-01-19_07:01:00UTC
So, well, date arithmetic is being done, just not the one that we asked for. ¯\(ツ)/¯
Best Answer