t3make vs. winter time

Authoring TADS
1

now are 02:30 CEST, that is, half hour from now will be 02:00 CET here in Italy (that is, back to solar hour), and I’m working in TADS3. that is, compiling with t3make, which works like, well make(1).

Now, the issue is well-known: the new files have actually earlier timestamp than old files (a file saved at 02:10 CET is actually newer than one saved at 02:35 CEST) with the probable (depends how the make and/or compiler handle the timestamp) refusal of compiling “older” files.

Yes, I know about touch(1) but honestly, there’s a better handling than touch all *.t at 02:01 CET ?

perplexed regards from Italy,
dott. Piergiorgio.

1 Like
2

I used to perform time changes manually on my computer – change the hardware clock and then the system’s clock, at a time which was convenient for me.

I had to stop doing that (and have ntp running) so I could use TOTP authentication, which requires your computer (etc) to be in complete sync with everything else on the internet.

3

also here is automatically handled (plus, every day is synced with time signal) in… two and half minutes from now.

I have done the simpler solution: NOT saving. Granted, this can led to longer debug time (and risking losing ~1h work) but allows having “good” timestamps :slight_smile:

Best regards from Italy,
dott. Piergiorgio

4

02:00 bis, saved all in the editor, rm obj/* for good extra measure, compiled, and all is as should be:

~/if/wrk/tads3/isekai$ ls -l isekai.t3
-rw-r--r-- 1 pigi pigi 1780115 26 ott 02.00 isekai.t3

(I’ll fess up: after the apocalyps3 fiasco, I’m very cautious with unusual timestamps…)

Best regards from Italy,
dott. Piergiorgio.

2 Likes
5

The best handling is…doing nothing at all. All the OS cares about is the timestamp, and the timestamp is agnostic about the local timezone.

When you see a file modification time (via something like ls -l) what you’re seeing is the human-readable local date corresponding to the UNIX timestamp in the file’s inode.

One second before the change, the UNIX timestamp will be 1761440399. A file created at the moment will have that timestamp in its inode. One second later the timestamp will be 1761440400.

If you ask your computer what time those timestamps are, it’ll tell you:

# date -d "@1761440399"
Sun Oct 26 02:59:59 CEST 2025
# date -d "@1761440400"
Sun Oct 26 02:00:00 CET 2025

Figuring out if “Sun Oct 26 02:59:59 CEST 2025” comes before or after “Sun Oct 26 02:00:00 CET 2025” is confusing, but figuring out if 1761440399 is greater than or less than 1761440400 is straightforward.

5 Likes