On OS/X or FreeBSD, it's the -U option. Linux now also stores the birth/creation time on most of its native file systems, but there's no API to retrieve it yet (2018 edit: since kernel 4.11, there is now a
statx() system call, and since glibc 2.28 a libc wrapper for it and since coreutils 8.31, GNU
stat can display it).
On ext4 filesystems, you can use debugfs to get it though:
$ sudo debugfs /dev/some/fs
crtime: 0x53208d7a:9045625c -- Wed Mar 12 16:38:18 2014
/some/file is the path within that filesystem)
For NTFS filesystems, and assuming you're using ntfs-3g to mount it, see How do I get the creation date of a file on an NTFS logical volume?
If you have a recent enough Linux system, you can use
xfs_io to invoke the new
statx system call and get the birth time:
$ TZ=UTC0 xfs_io -c 'statx -v' a
stat.btime = Thu Feb 7 17:11:20 2019
(here using UTC time with
TZ=UTC0 as otherwise the date would be ambiguous as the UTC offset is not output). Or with
statx -r which gives you the nanosecond part and a more easily parseable time:
$ xfs_io -c 'statx -r' a
stat.btime.tv_sec = 1549559480
stat.btime.tv_nsec = 964691587
See also this other Q&A for a way to invoke
statx() when your kernel is new enough to support it but when your libc is not.
stat 8.31 or newer on systems with glibc 2.28 on newer and a kernel 4.11 or newer:
$ stat a | grep Birth:
Birth: 2018-05-24 16:27:28.415875403 +0100
$ stat -c '%.9W %w' a
1527175648.415875403 2018-05-24 16:27:28.415875403 +0100
Traditionally, Unix didn't store a creation time.
Note that that value maybe has less meaning that you might think. The modification time reflects the age of the data in that file, the access time when it was last accessed, the inode change-time is very useful to backup software for instance, because you know nothing about that file has changed since that time (except possibly its full path for which you can have a look at the ctime of its directory components).
The creation time is when the inode spawn into existence (well had a link count going from 0 to 1, that inode might have been allocated and removed in a previous life), it doesn't reflect the age of any data associated with that file (data is written after the file has been created), it doesn't tell us whether a file by that path went into existence at that time (the file we're looking at can have been created with a different path and linked or moved there later).