Script Help: epoch time conversion

[franton]

Hi all,

Help.

I'm trying to convert output from "date" command to epoch time. So far I got this:

date –j –f "%a %d %b %Y %H:%M:%S %Z" “Fri 3 Jan 2014 17:13:46 GMT” +"%s" date: illegal time format usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]

Can someone point me in the right direction?

[bentoms]

Any help?

http://erikslab.com/2007/10/06/getting-the-current-time-in-epoch-seconds/

[franton]

He's doing it the other way round to me. I need to go from a date to an epoch time.

[tlarkin]

Do you just want the current epoch time?

$ date +%s
1391801318

Are you looking to convert previous dates to epoch time? Give us a bit more info and someone here can answer your question.

Thanks,
Tom

[franton]

The command I showed should convert the standard output of the date command into epoch time. Except it doesn't.

I have a file on each mac that contains from the date command, the last time they were updated. I need to compare that to the current date command output to see if they're past a 30 day mark. Converting to epoch time would help this along nicely.

[franton · Accepted solution]

Jesus wept.

The BSD version of the date command has probably the nastiest syntax of any unix command ever. The GNU versions on RHEL and other unixes aren't nearly as finicky.

The actual command to do what I needed is this:

date -j -f '%a %d %b %Y %T %Z' "Fri 3 Jan 2014 17:13:46 GMT" '+%s'

The difference is the removal of the %H %M %S for hours minutes and seconds. Replacing those with %T for time does the trick.

It's Friday. It's 8:30pm. I'm going home. Thank you for your efforts everyone.

[bradtchapman]

Jesus still weeps. This conversion works in 10.9.x, but not in 10.10.x:

Mavericks:

mavericksmac:Shared root# date -j -f "%a %b %d %T %Z %Y" "Mon Nov 2 11:22:25 PST 2015" +"%Y-%m-%d %T"
2015-11-02 11:22:25

Yosemite:

mymac:Shared root# date -j -f "%a %b %d %T %Z %Y" "Mon Nov 2 11:22:25 PST 2015" +"%Y-%m-%d %T"

Failed conversion of ``Mon Nov 2 11:22:25 PST 2015'' using format ``%a %b %d %T %Z %Y''
date: illegal time format
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]

FYI the dashes appear a bit long in this example, but they are definitely regular hyphens and not en–dashes.

[thoule]

I think California finally fell into the ocean. If you change the timezone to one that still exists, your command works fine.

[mm2270]

@bradtchapman Seems like it has something to do with the timezone, i.e, the PST for me is messing it up. If I copy/paste your command and run it as is in Yosemite I see the same failure output. If I up arrow the command and simply change the "PST" to "EST" and run it again, its successful. I'm located in EST so I don't if ones locale has something to do with that, but basically its not liking the timezone format being presented, though I'm not sure why just yet. When just printing out a date format, not doing a conversion, using %Z will print the current timezone just fine, so using it for a time format conversion should work, yet it doesn't. Very strange. Even stranger that it would work OK in 10.9, but not in 10.10.

[thoule]

Mike, you do put it so much nicer than me. :) I'm thinking there is a bug in the date program...?

THOULE$ env TZ=US/Pacific date
Wed Jan 13 13:13:51 PST 2016
THOULE$ env TZ=US/Eastern date
Wed Jan 13 16:13:58 EST 2016
THOULE$ date -j -f "%a %b %d %T %Z %Y" "Wed Jan 13 16:13:58 EST 2016" +"%Y-%m-%d %T"
2016-01-13 16:13:58
THOULE$ date -j -f "%a %b %d %T %Z %Y" "Wed Jan 13 13:13:51 PST 2016" +"%Y-%m-%d %T"
Failed conversion of ``Wed Jan 13 13:13:51 PST 2016'' using format ``%a %b %d %T %Z %Y''
date: illegal time format
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]

[mm2270]

@thoule Sure seems like a bug to me, because it makes no sense at all.
And I didn't even see your post honestly until just now. That explanation makes sense too. :-D Just to note though, I tried it with CDT, CST and CT also and they all fail as well. Heck, I changed it to GMT even and it fails, so most definitely a bug. IOW, unless I use a timezone that I'm actually in (or at least that my Mac thinks its in) then it fails. Stupid date thing-y.

[bradtchapman]

Not sure if bug, but the conversion fails in Mavericks too if the Time Zone is not the same as the local machine. That's infuriating.

[thoule]

I changed my computer's timezone to PST, and now that works and EST Doesn't! So for me, only GMT and (current timezone) works. Thanks Apple!

[erikberglund]

For the date command to read your input correct, you have to specify the input correct as well, so, for the date command to read PST correct, you need to supply that as an environment variable. Also, it's sensitive about the localization as well, so it's also a good idea to specify the LANG environment variable aswell, as your input is in the english locatization, in case you're on a system with a different setting (like mine).

So, just add these before the command for the PST timezone:

LANG=C TZ=PST8PDT

Which looks like this:

Demo:~ erikberglund$ LANG=C TZ=PST8PDT date -j -f "%a %b %d %T %Z %Y" "Mon Nov 2 11:22:25 PST 2015" +"%Y-%m-%d %T"
2015-11-02 11:22:25

[bradtchapman]

That's so dumb.

The point of having the %Z variable is so that it reads that chunk of data, expecting a time zone, and processes it accordingly. Based on %T %Z alone, it should be able to convert that into GMT and epoch.

[thoule]

@bradtchapman I recommend you enter a feature request ;)

It seems the date command reads the file /usr/share/zoneinfo/America/New_York. (I'm in EST timezone). My guess is that it needs to know the difference between GMT and <localtime> to do the calculations. If I try to run PST data from EST, then that info isn't in the New_York zoneinfo file so it fails out. Either changing your timezone to match, or, as @erikberglund said, use an environment variable, will allow it to find the correct zoneinfo file and complete the calculation.