https://gitlab.synchro.net/main/sbbs/-/commit/445394f9fc31d3d40261737c
Modified Files:
src/sbbs3/atcodes.cpp bulkmail.cpp email.cpp getmsg.cpp js_bbs.cpp js_msgbase.c mailsrvr.c msgdate.c msgtoqwk.cpp netmail.cpp postmsg.cpp qwk.cpp qwknodes.c qwktomsg.cpp readmail.cpp readmsgs.cpp sbbsecho.c smbutil.c writemsg.cpp src/smblib/smbadd.c smbdefs.h smbdump.c smblib.c smblib.h
Log Message:
Encode local wallclock (not time_t) in SMB's when_t.time

Increment SMBLIB version to 3.10

Fix issue #845: Changing system/OS time zone, changes dates/times of posted messages

Sysops and users shouldn't notice any change unless they change the time zone of their system/OS (not accounting changes for daylight/standard time) and
the result will be that message dates appear the same after such a change.

For backward compatibily, any stored time_t's in msghdr_t.when_written.time (i.e. all existing SMB messages) will still be decoded and displayed properly. We detect a time_t value by the upper 6 bits being non-zero. When the upper
6 bits of a when_written.time value are zero, then we know the 'year' is
stored in the 16-bits before the when_written field (never used bits of the netattr field, now part of the when_t structure definition) and the Month,
Day, Hour, Minute, and Second of the wallclock at the poster's site are
encoded in the low 26 bits of the time field.

This also eliminates more uses of 32-bit time_t that'll likely start being
a problem 2038 and really fall over and die in 2106. At least messages'
posting dates won't have any issue now. The "when_imported" values could use
a similar treatment someday I suppose - and we could get rid of the when_imported.zone value as its not really needed we could use those 16-bits for the when_imported.year.

Didn't change anything with filebases (still using time_t's though the when_written hdr field isn't used for much with regards to files).

Yes, we could have converted all imported "broken down" message dates to
UTC and continued to store them as a time_t using timegm() instead of mktime() for conversion to time_t, and I considered that. But we would have needed to create/use a flag in the message header to indicate such stored date/times (since they'd have to go through different adjustment for original time zone before display, basically reversing the logic of all the places we display the message dates/times using localtime verus gmtime/UTC C RTL functions),
couldn't just initialize the time with a call to time() upon import of local messages (unless the local timezone happened to be UTC). And in the end, we'd still have a 32-bit time_t value. So this seemed the better path.

I would have liked to have stored the date fields in a more human readable encoding (BCD or decimal, ala isoDate and isoTime_t), but I just didn't have the spare bits in the fixed portion of message headers to be wasteful like that.

Here's an example from smbutil v of a message header posted after this change:
when_written 03292595 41E0 Fri Dec 20 18:22:21 2024 PST
when_imported 6766265D 41E0 Fri Dec 20 18:22:21 2024 PST

Notice the difference in the hex encoding of the date/time between the 2
header fields: when_imported still uses time_t. The when_written.year value isn't output here.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net