Howdy,

So I just did a new compile, and updated my test environment and alterant. They are built from commit 4bb08eded

I posted a message on my test environment, which is configured for PST (UTC-08:00):

when_written 6764CF1E FE20 Fri Dec 20 12:57:50 2024 UTC-8:00
when_imported 6768D85E 412C Mon Dec 23 14:26:22 2024 EST

And on alterant, it's showing you new time hex, but the date string is off by one day:

when_written 03271E72 FE20 Thu Dec 19 17:57:50 2024 UTC-8:00
when_imported 6768D894 9258 Mon Dec 23 14:27:16 2024 AEDT

Looks like I had my test enviornment configured wrong date confirmed PST, but scfg -> System -> Local Time Zone I must have selected EST. I noticed this, because alterant was reporting:

Thu Dec 19 2024 05:57 pm UTC-8:00 (3.1 days ago)

and my test environment is reporting:

Fri Dec 20 2024 12:57 pm UTC-8:00 (2.3 days ago)

(I expected the difference in "days ago" to be the same, so I'll try again to be sure.)


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Commit f9ad15e8 might need more work :)
By: deon to Digital Man on Mon Dec 23 2024 02:42 pm

Howdy,

So I just did a new compile, and updated my test environment and alterant. They are built from commit 4bb08eded

I posted a message on my test environment, which is configured for PST (UTC-08:00):

when_written 6764CF1E FE20 Fri Dec 20 12:57:50 2024 UTC-8:00

I'm not sure how you posted that message, but the hex value there (for when_written.time) is a time_t not the bit-field-endoded date that's used in commit 4bb08eded. So something's amiss.

And on alterant, it's showing you new time hex, but the date string is off by one day:

when_written 03271E72 FE20 Thu Dec 19 17:57:50 2024 UTC-8:00 when_imported 6768D894 9258 Mon Dec 23 14:27:16 2024 AEDT

Looks like I had my test enviornment configured wrong date confirmed PST, but scfg -> System -> Local Time Zone I must have selected EST. I noticed this, because alterant was reporting:

Thu Dec 19 2024 05:57 pm UTC-8:00 (3.1 days ago)

and my test environment is reporting:

Fri Dec 20 2024 12:57 pm UTC-8:00 (2.3 days ago)

Weird that you've got 3 different time zones (PST, EST, and AEDT) going on between 2 systems.
--
digital man (rob)

Synchronet "Real Fact" #82:
Flapuebarg unf vagreany ebg13 fhccbeg sbe fhcresvpvnyyl rapelcgvat grkg
Norco, CA WX: 56.1øF, 75.0% humidity, 0 mph NE wind, 0.00 inches rain/24hrs
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Commit f9ad15e8 might need more work :)
By: Digital Man to deon on Sun Dec 22 2024 07:51 pm

Howdy,

Weird that you've got 3 different time zones (PST, EST, and AEDT) going on between 2 systems.

Yup, it is very weird - but a scenario that a sysop could be in, if the have to set the SBBS time seperately to the OS time.

So alterant OS is UTC+11:00, and scfg -> system -> local time zone is the same.

My test environment has the OS as PST (utc -8:00) and I had scfg -> system -> local time zone EST (utc -5:00) - but, the "wall clock" is way off...

Anyway, when I set the test environment back to scfg -> system -> local time zone back to PST (OS unchanged), then the displayed time string is OK.

TEST (UTC -8:00)
X-FTN-PID Synchronet 3.20a-Linux master/4bb08eded Dec 23 2024 GCC 10.2.1 when_written 6764CE34 FE20 Fri Dec 20 12:53:56 2024 UTC-8:00
when_imported 6768E8E2 41E0 Mon Dec 23 15:36:50 2024 PST

ALTERANT (UTC +11:00)
X-FTN-TID SBBSecho 3.23-Linux master/4bb08eded Dec 23 2024 GCC 10.2.1 when_written 0328CD78 FE20 Fri Dec 20 12:53:56 2024 UTC-8:00
when_imported 6768E8F8 9258 Mon Dec 23 15:37:12 2024 AEDT

I'm not sure how you posted that message, but the hex value there (for when_written.time) is a time_t not the bit-field-endoded date that's used in commit 4bb08eded. So something's amiss.

I wasnt worried about the hex value for when_written_time being off (since I dont trust it to be utc anymore), but rather the text of the date, it was off by more than 3hrs (the difference between utc/pst). Interestingly it looks like it is out by 19hrs which is the OS timezone difference between the two systems.

(This timezone stuff is messy - but I get I'm probably a unique case, if I'm the only one that ends up bringing it up. I'm sure most folks will end of up with OS timezone = Sync timezone)

I posted that message with save_msg(), but I used
hdr.date = strftime("%a, %d %b %Y %H:%M:%S %z",this.__properties__.date)

(and __properties__.date is the File().date of a file where the contents are in the message body (1734659870)).

stat -c '%X' text/extra/100219b

1734659870


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Commit f9ad15e8 might need more work :)
By: deon to Digital Man on Mon Dec 23 2024 05:11 pm

Howdy,

I'm not sure how you posted that message, but the hex value there (for when_written.time) is a time_t not the bit-field-endoded date that's used in commit 4bb08eded. So something's amiss.

Oh boy... So I just had another look at this:

My test system (which is PST for OS and Sync):

But to be sure, I just posted another message:

X-FTN-PID Synchronet 3.20a-Linux master/4bb08eded Dec 23 2024 GCC 10.2.1 when_written 6764CF1E FE20 Fri Dec 20 12:57:50 2024 UTC-8:00
when_imported 6769155F 41E0 Mon Dec 23 18:46:39 2024 PST

A few things here:

a) when_written
The file that the date is based off of:

root@ansitex-dev# stat -c '%x' text/extra/100219b
2024-12-19 17:57:50.286025007 -0800

To confirm:
root@ansitex-dev# jsexec -n tools/test-strftime
File Date: 1734659870
Thu, 19 Dec 2024 17:57:50 -0800

And the contents of test-strftime.js

var f = new File('text/extra/100219b');
var fdate = f.date;
writeln('File Date: '+fdate);
writeln(strftime("%a, %d %b %Y %H:%M:%S %z",fdate));

So how is it getting when_written_time Fri Dec 20 12:57:50 2024?

b) when_imported_time
I dont set this value, so it is automatically calculated right?

root@ansitex-dev# date
Sun Dec 22 23:48:39 PST 2024

root@ansitex-dev# ls -al /etc/localtime
lrwxrwxrwx 1 root root 39 Dec 22 18:06 /etc/localtime -> /usr/share/zoneinfo/America/Los_Angeles

Startup:
synchronet: term Compiled master/4bb08eded Dec 23 2024 10:39 with GCC 10.2.1 synchronet: web Synchronet Web Server Version 3.20a
synchronet: web Compiled master/4bb08eded Dec 23 2024 10:39 with GCC 10.2.1 synchronet: term Initializing on Sun Dec 22 23:34:25 2024 with options: 2c02 synchronet: web Initializing on Sun Dec 22 23:34:25 2024 with options: 810

Where is it getting Mon Dec 23 18:46:39 from ? (Which coincidently, the AU local time right now.)


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Commit f9ad15e8 might need more work :)
By: deon to Digital Man on Mon Dec 23 2024 05:11 pm

Yup, it is very weird - but a scenario that a sysop could be in, if the have to set the SBBS time seperately to the OS time.

I thought we agreed that's an unlikely useful configuration, hence I added the "Automatic time zone" setting and made that the default. Just use that.
--
digital man (rob)

Steven Wright quote #4:
99% of lawyers give the rest a bad name.
Norco, CA WX: 52.1øF, 78.0% humidity, 0 mph NE wind, 0.00 inches rain/24hrs
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Commit f9ad15e8 might need more work :)
By: deon to Digital Man on Mon Dec 23 2024 07:10 pm

Re: Commit f9ad15e8 might need more work :)
By: deon to Digital Man on Mon Dec 23 2024 05:11 pm

Howdy,

I'm not sure how you posted that message, but the hex value there (for when_written.time) is a time_t not the bit-field-endoded date that's used in commit 4bb08eded. So something's amiss.

Oh boy... So I just had another look at this:

My test system (which is PST for OS and Sync):

But to be sure, I just posted another message:

X-FTN-PID Synchronet 3.20a-Linux master/4bb08eded Dec 23 2024 GCC 10.2.1 when_written 6764CF1E FE20 Fri Dec 20 12:57:50 2024 UTC-8:00 when_imported 6769155F 41E0 Mon Dec 23 18:46:39 2024 PST

How are you posting that message? When I post messages using the terminal server or using smbutil to import a message, I'm seeing the bit-encoded date values in hex (with the '0' initial nibble).

A few things here:

a) when_written
The file that the date is based off of:

root@ansitex-dev# stat -c '%x' text/extra/100219b
2024-12-19 17:57:50.286025007 -0800

To confirm:
root@ansitex-dev# jsexec -n tools/test-strftime
File Date: 1734659870
Thu, 19 Dec 2024 17:57:50 -0800

And the contents of test-strftime.js

var f = new File('text/extra/100219b');
var fdate = f.date;
writeln('File Date: '+fdate);
writeln(strftime("%a, %d %b %Y %H:%M:%S %z",fdate));

time_t values don't have a time zone, so printing '%z' there isn't really useful. It's just always going to print your system/OS time zone.

So how is it getting when_written_time Fri Dec 20 12:57:50 2024?

I'm confused about your time zone settings and systems, so I'm not really following.

b) when_imported_time
I dont set this value, so it is automatically calculated right?

Yes.

root@ansitex-dev# date
Sun Dec 22 23:48:39 PST 2024

root@ansitex-dev# ls -al /etc/localtime
lrwxrwxrwx 1 root root 39 Dec 22 18:06 /etc/localtime -> /usr/share/zoneinfo/America/Los_Angeles

Startup:
synchronet: term Compiled master/4bb08eded Dec 23 2024 10:39 with GCC 10.2.1 synchronet: web Synchronet Web Server Version 3.20a
synchronet: web Compiled master/4bb08eded Dec 23 2024 10:39 with GCC 10.2.1 synchronet: term Initializing on Sun Dec 22 23:34:25 2024 with options: 2c02 synchronet: web Initializing on Sun Dec 22 23:34:25 2024 with options: 810

Where is it getting Mon Dec 23 18:46:39 from ? (Which coincidently, the AU local time right now.)

Doesn't sound like a coincidence.

I'm going to play with jsexec posting of messages and see if I can reproduce the time_t when_written storage like you're showing.
--
digital man (rob)

Sling Blade quote #10:
Morris: I stand on the hill, not for thrill, but for the breath of a fresh kill Norco, CA WX: 52.3øF, 79.0% humidity, 1 mph ENE wind, 0.00 inches rain/24hrs --- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Commit f9ad15e8 might need more work :)
By: deon to Digital Man on Mon Dec 23 2024 05:11 pm

I posted that message with save_msg(), but I used
hdr.date = strftime("%a, %d %b %Y %H:%M:%S %z",this.__properties__.date)

The 'date' property is specifically for importing from RFC822-formatted messages. You probably shouldn't be using that.
--
digital man (rob)

Steven Wright quote #1:
I'd kill for a Nobel Peace Prize.
Norco, CA WX: 52.3øF, 79.0% humidity, 1 mph ENE wind, 0.00 inches rain/24hrs --- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Commit f9ad15e8 might need more work :)
By: Digital Man to deon on Mon Dec 23 2024 01:05 am

hdr.date = strftime("%a, %d %b %Y %H:%M:%S %z",this.__properties__.date)

The 'date' property is specifically for importing from RFC822-formatted messages. You probably shouldn't be using that.

Isnt strftime("%a, %d %b %Y %H:%M:%S %z") resulting in an RFC822 format?

https://validator.w3.org/feed/docs/error/InvalidRFC2822Date.html
and https://www.w3.org/Protocols/rfc822/#z28

Although the later link says a 2 digit year.

What about this format is incorrect (it appeared to result in the correct when_written_time before I updated).


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Commit f9ad15e8 might need more work :)
By: Digital Man to deon on Mon Dec 23 2024 01:03 am

Howdy,

How are you posting that message? When I post messages using the terminal server or using smbutil to import a message, I'm seeing the bit-encoded date values in hex (with the '0' initial nibble).

I answered this in another message - I'm using save_msg() with hdr.date = rfc822 date (it works, even with the timezone). That must not be using your new format for when_written_time yet.

I figured out why the strftime was messing up (when I first started using hdr.date to save messages that triggered this timezone discussion) - I had logging on and noticed it changed after 1pm - I was using %I instead of %H (which is what I always use, dont know where %I came from or why I used it).

I'm confused about your time zone settings and systems, so I'm not really following.

OK, I'm sorry for messing you around, and thanks for looking at it. Looks like I sent you on a red herring.

I run sbbs in docker, and I have 2 containers running sharing the same config and dirs (one sees a different login.js/logon.js that launches my ansitex shell on connection).

While I thought I had shutdown one container while posting these messages about the date/times - I just discovered I hadnt - and it's OS was still configured with UTC+11:00 (which explains where the aus date strings must have coming from). Probably would have discovered it quicker if I had change scfg -> System -> Local Time Zone to Auto after updating ;)

My other container (which is likely I wasnt connected to) was configured to PST, and I was logging the console, so I saw the terminal server recycle when playing with scfg (setting PST) and the logs when binkit was triggered sending messages.

So, I killed everything, and started just the PST container, posted messages and they are infact the correct time string - for both the when*time values. When using save_msg() with hdr.date, it doesnt use your new when_written_time encoding though.

When I changed the OS back to AEDT (and I'm now using the Auto Time zone - winner :), the rendering of the message showed the wall clock time that you were after, and rendered the correct "minutes ago" age message.

Sorry for the run around - On the upside, I understand sync's internals better ;)


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Commit f9ad15e8 might need more work :)
By: deon to Digital Man on Mon Dec 23 2024 10:30 pm

Re: Commit f9ad15e8 might need more work :)
By: Digital Man to deon on Mon Dec 23 2024 01:05 am

hdr.date = strftime("%a, %d %b %Y %H:%M:%S %z",this.__properties__.date)

The 'date' property is specifically for importing from RFC822-formatted messages. You probably shouldn't be using that.

Isnt strftime("%a, %d %b %Y %H:%M:%S %z") resulting in an RFC822 format?

That's likely correct (for your time zone), but unnecessary (converting to/from string format). Just set when_written_time to a time_t value (e.g. the return value of time() or fdate()).

https://validator.w3.org/feed/docs/error/InvalidRFC2822Date.html
and https://www.w3.org/Protocols/rfc822/#z28

Although the later link says a 2 digit year.

Synchronet will parse 2 or 4+ digit year.

What about this format is incorrect (it appeared to result in the correct when_written_time before I updated).

I'm not saying the format is incorrect, I'm saying that you don't need to go through the extra gyrations. That said, you found a bug (lack of conversion to to the new date/bit-field encoding) - now fixed. :-)
--
digital man (rob)

Breaking Bad quote #5:
Sometimes the forbidden fruit tastes the sweetest. - Hank Schrader
Norco, CA WX: 68.8øF, 42.0% humidity, 2 mph WSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Commit f9ad15e8 might need more work :)
By: deon to Digital Man on Mon Dec 23 2024 11:53 pm

So, I killed everything, and started just the PST container, posted messages and they are infact the correct time string - for both the when*time values. When using save_msg() with hdr.date, it doesnt use your new when_written_time encoding though.

That should be fixed now though. Thanks for testing!
--
digital man (rob)

Synchronet/BBS Terminology Definition #59:
PCMS = Programmable Command and Menu Structure (introduced in SBBS v2)
Norco, CA WX: 68.8øF, 42.0% humidity, 2 mph WSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)