time_zone of ISO-IMAGES time_stamps

[spellberg_robert]

2025_jun_09_mon 17.17.--.utc

howdy , all ---

i hope that every_one is well ; we are just fine , thank you .



since the early 4s , i have been buying pressed dvds from freebsd_mall .
thus , i have a complete set , from there , through 13.3 and 14.2
[ i386 , then amd64 ; cd , then dvd ] .

for some reason [ i will inquire , separately ] ,
13.4 and 13.5 never arrived [ typically , ~ 4 weeks after release ] .
[ no , i was not charged for these ; so , no problem there . ]

in anticipation of replacing , finally , a 11.4 box , w/ 13.5
[ of course , there are other boxen , w/ later releases ,
but , none have the last of the 13s ] ,
earlier today , i down_loaded the 13.4 and 13.5 iso and sum files .

by way of example , please consider this page :
"https://download.freebsd.org/releases/ISO-IMAGES/13.5/" .

it is nice to see that each of the files has an associated time_stamp ,
but , there is no indication of the applicable time_zone .

it would be easy to assume that these are all "utc" , --but-- ,
we all know about the inherent danger in making an assumption .



question_a :
do all of the various time_stamps use the same zone or
can the zone vary ?

question_b :
if consistent , which zone is in force ?

question_c [ clean ] :
if consistent , could the applicable zone be specified ,
in the top_of_page header ?

question_d [ messy ] :
if variable , could the zone be specified w/ the stamp ?



i realize that , because of the global nature of the fbsd project ,
these time_stamps are , in all probability , consistently "utc" .
none_the_less , i have learned that it is better to ask ,
rather than to assume .



i extend my best to each of you and to your respective yours .

tia ,

rob

[Edward Sanford Sutton, III]

On 6/9/25 10:17, spellberg_robert wrote:
> 2025_jun_09_mon 17.17.--.utc
>
> howdy , all ---
>
> i hope that every_one is well ; we are just fine , thank you .
>
>
>
> since the early 4s , i have been buying pressed dvds from freebsd_mall .
> thus , i have a complete set , from there , through 13.3 and 14.2
>   [ i386 , then amd64 ; cd , then dvd ] .
>
> for some reason [ i will inquire , separately ] ,
>   13.4 and 13.5 never arrived [ typically , ~ 4 weeks after release ] .
> [ no , i was not charged for these ; so , no problem there . ]
>
> in anticipation of replacing , finally , a 11.4 box , w/ 13.5
>   [ of course , there are other boxen , w/ later releases ,
>       but , none have the last of the 13s ] ,
>   earlier today , i down_loaded the 13.4 and 13.5 iso and sum files .
>
> by way of example , please consider this page :
>   "https://download.freebsd.org/releases/ISO-IMAGES/13.5/" .
>
> it is nice to see that each of the files has an associated time_stamp ,
>   but , there is no indication of the applicable time_zone .
>
> it would be easy to assume that these are all "utc" , --but-- ,
>   we all know about the inherent danger in making an assumption .

Unless someone more directly responsible or knowledgable speaks up,
I'd say the assumption is on track. I do appreciate corrections if so.
UNIX systems should prefer to know when UNIX time counting started
based off of the count of seconds from that exact moment in time. When
that was at is an exact point in time that happened at the same moment
despite a local timezone conversion. UTC is a common way to express an
exact moment so that everyone can know the difference between their
timezone and a reference without memorizing all timezone offsets and
their conditional rules; learn UTC and how yours changes and have
someone elsewhere with that knowledge and you can communicate time
without extra effort.
Normally a good use of timestamps is to write everything in UTC to
the filesystem. When you set your timezone your system translates UTC
filesystem data to match your timezone just for user interface but still
remembers UTC. If you move timezones, you don't have to rewrite all that
filesystem metadata because none of it has any reason to change. Same is
true for 'daylight savings' timezone alterations.
The time is translated from UTC to the local time just for display
purposes but avoids the complications hitting the filesystem like 'this
file was written before daylight savings time so now is written in the
future' when near a transition.
Users can set an exception to say their motherboard clock is set to
the time zone time instead of UTC. Only reason I'd consider that is for
machines regularly booted to an operating system with a poor
understanding of UTC (think Windows is still that way) or 'maybe' to be
able to set BIOS/UEFI timers for scheduled activities and not have to
teach someone what UTC is to do it (or avoid human mistakes doing it).
FreeBSD used to ask if the motherboard clock is set to UTC or a time
zone during install but that feature was removed. I don't think it is
still an option once removed and now requires 'manually' telling the
system the motherboard is not UTC. If you need it, I think the starting
place now is `man tzsetup`.

> question_a :
>   do all of the various time_stamps use the same zone or
>     can the zone vary ?

My understanding is time stamps of files do not, and should not store
the time zone. If you find an option of using UTC vs timezone within a
filesystem, just save yourself headaches and tell it to stick to UTC if
you want to eliminate such headaches and questions. If you care about or
need accurate timestamps, never run a local timezone on the motherboard
without telling FreeBSD that timezone.