I started working at my current position since November 17th 2014. I would like to know how many days have run up to now. Any ideas on how to use Linux to come up with a simple and nice solution?
Asked
Active
Viewed 4,181 times
11
-
I ended up doing something similar in a perl script; I used the timelocal() function to get the number of seconds from the epoch to the given date (Nov 17, 2014 for example), then subtracted that from the current epoch-date-in-seconds, then divided by 86400 (seconds in a day). I'm sure someone will come through with a shell-only solution :) – Jeff Schaller Jul 14 '15 at 14:25
-
2Time arithmetic has lots of fiddly special cases. While simple things like subtracting UNIX timestamps and dividing by 86,400 will give you an approximate answer, you are better off using a specialized time library that takes into account the special cases, for example Python's `dateutil`. – Reid Jul 14 '15 at 16:16
-
1Some of the answers in [Quickly calculate date differences](http://unix.stackexchange.com/questions/24626/quickly-calculate-date-differences) may help here too. – manatwork Jul 14 '15 at 18:36
-
http://24.media.tumblr.com/tumblr_m4bph9tiPe1r9kuhvo1_250.gif – msh210 Jul 15 '15 at 06:46
-
@msh210 you are banned for life and sentenced to prison for 1 month while serving community as code cleaner for ancient COBOL code. – ychaouche Apr 12 '17 at 08:46
4 Answers
15
echo $(( (`date +%s` - `date +%s -d '2014/11/17'`) / 86400 )) days ago
wurtel
- 15,835
- 1
- 29
- 35
-
5This gets leap seconds wrong. I mean, that hardly matters *now*, but in [10k years or so](http://longnow.org/about/) the accumulated error could be enough to matter. – Kevin Jul 14 '15 at 19:07
-
2The probability leap seconds will trigger an error in about .000001%. This is negligible compared to the wrong number of days this method will give with locales where daylight saving time is observed: 2% of the cases ... – jlliagre Jul 14 '15 at 21:04
-
2@Kevin: If he wants to know how many days he worked somewhere, we can (until further advance in cryogenisation or medicine) not bother too much about this ^^ – Olivier Dulac Jul 15 '15 at 00:37
-
1
-
@Kevin the fact `date +%s` works in UTC doesn't change at all the fact the result will be sometimes incorrect in location where DST is in use. "The number of days since X" is timezone dependent, one cannot ignore that fact with pretending to be in UTC. – jlliagre Jul 15 '15 at 06:42
-
1Chances are he will be wondering about the number of days employed while idling behind his desk at work. As that's probably not around midnight but somewhere between 8am and 5pm (and `date -d 2014/11/17` gives a timestamp of midnight as there's no time mentioned) DST doesn't matter. – wurtel Jul 15 '15 at 07:32
5
Well, on the face of it:
$ date --date="-239 days"
Mon Nov 17 15:25:40 CET 2014
In a script (not very efficient, but... maybe it handles leap seconds? ;) )
i=0
result=""
while [ "$result" != "20141117" ]
do
i=$((i+1))
result=$(date --date="-$i days" +%Y%m%d)
done
echo "$i" days have passed since "$result"
frostschutz
- 47,228
- 5
- 112
- 159
-
-
1@DigitalTrauma too bad it's not localized. E.g. `LC_ALL=ru_RU.utf8 date --date="239 дней назад"` gives me the same result as `date --date="239"`. – Ruslan Jul 15 '15 at 04:31
-
1
I tried python on the command line.
$ python -c "import datetime; print datetime.date.today() - datetime.date(2014,11,17)"
246 days, 0:00:00
Diana Mackinnon
- 1
- 2
ychaouche
- 945
- 8
- 25
1
Here is example with PHP:
<?php
$o1 = date_create('2014-11-17');
$o2 = date_create();
$o3 = date_diff($o2, $o1);
echo 'days: ', $o3->days, "\n";
Result:
days: 1927
Zombo
- 1
- 5
- 43
- 62