Right now, it is "Mon Feb 9 23:21:07 PST 2009" or "1234250467" seconds since the Unix epoch.
When represented in base ten, the number of seconds since the epoch ("unixtime" henceforth) takes 11 code points (1) to represent, possibly the most efficient way to represent time with second granularity (If we represented the time in another base, we could save even more code points).
How hard is it to find the current unixtime? Easy, use the command:
$ date +%s
This command should work on any system where date(1) makes use of a POSIX compliant strftime(3) implementation.
So what's the big deal?
I use unixtime frequently to avoid making mistakes. For example, I use this command to "delete" a file instead of rm(1):
$ mv $file $file.`date +%s`
I also use it when I want to run a command several times and easily find the differences between each invocation:
$ some_command > output.`date +%s`
And finally: I frequently come across files on systems where, for whatever reason, using a real version control system is impractical or impossible. In these cases, the `date +%s` command comes in very handy as a super ghetto version control system. Some examples:
To do a "checkin"
$ cp $file $file`date +%s`
To compare an old "revision" with "HEAD"
$ diff -u $file.$old_unixtime $file
To take a "snapshot" of your "repository"
$ tar -cf utvc.`date +%s`.tar ./*
At my last job, I had a button mapped to type `date +%s` when it was pressed, I miss that button.
1: Until 2038, when it'll change to 12 code points. I use the term "code point" because I'm internationalized, yo.