Exactly.
Most Unix file systems are read and written from Unix machines. Most Unix machines are configured with the system clock running in UTC. If you do a system call (it's called gettimeofday) to get the time from the kernel, you get back a number (let's pretend it's an integer, since the milli- and nanoseconds aren't important), which is the number of seconds since a mythical "Midnight on January 1 1970 in Greenwich, England". Why do I say "mythical"? Because that calculation deliberately ignores the fact that leap seconds exist, and a human who started a stopwatch on New Year's Eve in 1970 would observe a different number, but it's pretty close (I think better than a minute).
That also implies that the time stamps of files, which are stored in Unix file systems (such as UFS, ZFS, ext2, ...) are numbers which are to be interpreted as Unix timestamps, usually in UTC. There is no difference between Unixes in this respect, this applies to Linux too.
Now, when you run the stat program from the shell, it prints those numbers are pretty-printed dates. For example:
Code:
# stat foo
1971592262 352434 -rw-r--r-- 1 ralph ralph 4294967295 13684 "Dec 19 18:00:43 2017" "Dec 18 11:54:18 2017" "Dec 18 11:54:18 2017" "Dec 18 11:54:18 2017" 13824 33 0x800 foo
# stat -r foo
1971592262 352434 0100644 1 1001 1001 4294967295 13684 1513735243 1513626858 1513626858 1513626858 13824 33 2048 foo
This tells me that the UTC time 1513626858 (this many seconds since the champagne flowed in Greenwich) happens to be equivalent to "Dec 18 2017, right before lunch namely 11:54, in my time zone" (which happens to be California). The important concept is: Unix thinks of its times as numbers, which are very simple second counters. Only when these numbers need to be displayed to humans, or parsed from humans, does it get converted to normal dates, and this is where time zones enter.
In order for this to work, the whole operating system (not just the kernel, more importantly the library and applications) need to know what time zone the system is in. That's set up with the tzsetup program. It is also possible for individual processes to change their own timezone and display
(Side tour: It is possible to run Unix machines with the system clock running in local time instead of UTC; in the very early days of Linux, like kernel 0.99.13, we used to mostly do this. It is a really bad idea, since it causes anguish and confusion. The only valid reason to do that is if the same hardware is regularly rebooted into early Windows versions, like Win 3.1, which can only have the system clock be set to local time; I think this hasn't been a problem for several decades now.)
Again: The time stamps in Unix file systems are just those UTC numbers. It would theoretically be possible to change the time zone of a machine and reboot it, and then the same file that was "Dec 18 11:54:18 2017" would suddenly show a different date. For example, if I change the time zone of my machine to New York time, it would display "Dec 18 14:54:18 2017", but the number stored on disk hasn't changed a bit. For most people, this problem does not occur, since they are not in the habit of changing the time zone and rebooting. Where it does happen is with cluster- and network file systems: If two different computers are looking at the same file system, but one is in the New York time zone, then it will see all the file dates looking different (this can happen with things like NFS or large-scale clusters). This is only a problem for stupid humans that look at those things; intelligent computers always compare the raw numbers, and those don't change.
Note that the Unix file system does NOT store the time zone information. The entry for the file foo in my home directory does not say "this file is in California". It simply says "this file was created 1513626868 seconds after midnight 1970 in Greenwich". The important thing is: this information is true and correct, whether you are in California, New York, or Timbuktu. Now whether the weekday is called "monday", "Montag", "lundi" or "segunda feira" is irrelevant to the correctness of those numbers. And those numbers are also correct independent of which time zone the human (a.k.a. "wetware") thinks they are in. I can take my computer, put it into the trunk, and drive to New York, and the numbers on disk do not have to change. I might run tzsetup after arriving in New York, and the file will *look* different, but the truth is still underneath it.
So far, everything is good and easy. Where it gets really fornicated is when stupid humans introduce their bad habits into the good computer data. Unfortunately, Windows machines used to run with the system clock set to local time (in the bad old days, I think modern Windows versions got better, but I don't care about Windows and don't remember the details). For that historical reason, the file times of FAT file systems (typically used on USB sticks today) are stored as local times. But within FAT, those times are also stored as numbers (let's not worry about whether they are integers or not, and whether they count in seconds or not, the reality is unspeakably complex), and the problem is the semantics or interpretation of these numbers. Sad fact of life is, on FAT those numbers mean something that's location dependent.
On FreeBSD, if you mount a FAT file system, it reports the time as if the USB stick were in UTC. There might be mount options to change that, but I don't know of any. That means that you will have to manually correct all these times, or know how to interpret them. I know that other operating systems are different; for example, if you mount a FAT file system on a Macintosh (OS X, which is interestingly a FreeBSD derivative), it automatically corrects the times for the local file system *of the computer*, not of the memory stick.
The classic example of problems caused by this are cheap digital cameras of video recorders. You set the local time on them (so when you look at their little display and it says "2pm", it's really afternoon). They then write that time as a local time as the time stamp of the .jpg file they put on disk. I take the memory card out (these days it's typically a SD card), mount it on my FreeBSD machine, and the same file displays as 5am, because my FreeBSD machine thinks the number is in UTC. Not a problem; I have a little utility that corrects files that come from my camera as they are copied (it's a little hack script called "rsync_camera" which internally uses another hack called "shift_utime"). Where it gets ugly: I run the same hack script on my Mac, and it gives me answers that are wrong by 9 hours, because on the Mac the OS has already corrected the times. And where it gets massively ugly: I go on vacation in Europe, set the local time on the camera to be "right", and end up with an SD card that's a mix of European and California times, and then my little hack script makes a giant mess, and I need to spend hours changing time stamps on files.
