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)

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: 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: 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)