in reply to Date to Epoch

perl -MPOSIX -e 'print strptime(<stdin>, "%s")'

For some reason, Perl's POSIX does not provide strptime, you'd need to install and use POSIX::strptime.

But if you have or can install the module Time::Piece (in core since 5.10), you can use its Time::Piece->strptime(STRING, FORMAT), it has a nicer interface.

Update:

$ echo "Mar 20 2018 09:00" | perl -wMstrict -MTime::Piece -nle 'print +Time::Piece->strptime($_,"%b %d %Y %H:%M")->epoch' 1521536400

If you want to use POSIX::strptime, you should also look into mktime, although at that point I'd really recommend using a better module. I usually use DateTime because it supports almost everything you'd need, but for simple tasks Time::Piece is enough.

Replies are listed 'Best First'.
Re^2: Date to Epoch (updated)
by ikegami (Patriarch) on Mar 20, 2018 at 20:33 UTC

    That should probably be localtime->strptime(...)->epoch

Re^2: Date to Epoch (updated)
by Anonymous Monk on Mar 20, 2018 at 14:33 UTC

    Thank you for the reply

    Time::Piece does not work in core 5.10, and I am unable to install any modules

    I did run across the following code though:

    print -e 'print scalar timelocal(2,16,10,20,2,2018)'

    This solution, however would require me to use external variables in some way

    echo "2,16,10,10,20,2,2018" | perl -e 'print scalar timelocal(<stdin>)'

    Does not recognize the data being pushed

      Time::Piece does not work in core 5.10

      I'm not sure what you mean? In my installations of 5.10.0 and 5.10.1 with Time::Piece 1.12 resp. 1.15 the code I showed works fine. If you are having trouble, see How do I post a question effectively?

      I am unable to install any modules

      That's unlikely - see Yes, even you can use CPAN and local::lib.

      If all you're doing is converting a date, perhaps see date, although it can't do quite as much as the Perl modules I've named.

      $ date -d "Mar 20 2018 09:00" +"%s" 1521532800

      Note there is a discrepancy of one hour to the output in my example above, most likely due to different time zone handling. It's always best to include time zone information with date/time strings or objects to avoid ambiguity.

      And, this solution would also require me to process the dates to numbers first

A reply falls below the community's threshold of quality. You may see it by logging in.