11

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?

Kusalananda
  • 333,661
ychaouche
  • 998
  • 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
  • 2
    Time 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
  • 1
    Some of the answers in 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 Answers4

15
echo $(( (`date +%s` - `date +%s -d '2014/11/17'`) / 86400 )) days ago
wurtel
  • 16,115
  • 5
    This gets leap seconds wrong. I mean, that hardly matters now, but in 10k years or so the accumulated error could be enough to matter. – Kevin Jul 14 '15 at 19:07
  • 2
    The 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
    @jlliagre: %s is Unix time, which is always UTC, which lacks DST. – Kevin Jul 15 '15 at 01:14
  • @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
  • 1
    Chances 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
  • 48,978
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
ychaouche
  • 998
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

https://php.net/function.date-diff

Zombo
  • 1
  • 5
  • 44
  • 63