Re: Re: FTN Packet's message date question
By: deon to slacker on Sat Dec 14 2024 09:11 pm

With clrghouz, the packet date, is the date of youngest (most recent) message in the packet, in UTC.

Do you support (generate or parse) type 2.2 packets? I ask because type 2.2 packet headers don't include a date.
--
digital man (rob)

Steven Wright quote #18:
Hard work pays off in the future; laziness pays off now.
Norco, CA WX: 61.2øF, 52.0% humidity, 2 mph SSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

Re: Re: FTN Packet's message date question
By: Digital Man to deon on Sat Dec 14 2024 04:33 pm

Howdy,

With clrghouz, the packet date, is the date of youngest (most recent) message in the packet, in UTC.

Do you support (generate or parse) type 2.2 packets? I ask because type 2.2 packet headers don't include a date.

Yes I do (both - generate and parse) - and I am aware of that.


...ëîåï
--- SBBSecho 3.20-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

Thanks for all the info! Sorry for the late reply on this...

I *think* I found the issue at least on some messages. It seems like it might be related to daylight savings and the kludge not getting updated on remote systems.

Example this message from earlier today:
AREA: FSX_STA :: MSG_ID: 21:1/100 67694287 :: FROM: 21:1/100 :: TO: 21:3/193 :: SUBJ: [NET1] Node Queue

FTSC_DATE: 23 Dec 24 23:59:18 :: TZOFFSET: 1200

BBS Log:
[2024-12-23 06:04:11.85648] [13813] [error] Parsed date time: 2024-12-23T11:59:18 is after current UTC date: 2024-12-23T11:04:11 even after TZ correction 1200 :: Using current UTC date for value.

I think coming from hub 1, the TZUTC offset should be 1300 now instead of 1200 for daylight savings, right? If I corrected for 1300, the time would have been valid and just 5 min before the current UTC time when I processed the packet.

Link to the message on clrghouz: https://clrghouz.bbs.dege.au/echomail/view/635493

I think I might be driving myself nuts for no reason lol. I poll every 30 min so current UTC of processing for received messages should be 'close enough'. I'll also take a look at using the packet date as you mentioned in a previous message. Maybe that would be a better choice than what I'm doing.. but again, I think I might just be over thinking this. :)


--- NE BBS v0.76 (linux; x64)
* Origin: NE BBS - nebbs.servehttp.com:9223 (21:3/193)

Re: Re: FTN Packet's message date question
By: slacker to deon on Mon Dec 23 2024 07:23 pm

Howdy,

FTSC_DATE: 23 Dec 24 23:59:18 :: TZOFFSET: 1200

BBS Log:
[2024-12-23 06:04:11.85648] [13813] [error] Parsed date time: 2024-12-23T11:59:18 is after current UTC date: 2024-12-23T11:04:11 even after TZ correction 1200 :: Using current UTC date for value.

I think coming from hub 1, the TZUTC offset should be 1300 now instead of 1200 for daylight savings, right? If I corrected for 1300, the time would have been valid and just 5 min before the current UTC time when I processed the packet.

Yes, you are correct. I just looked at the packet I received from Hub 1,and it does have TZUTC 1200. It should be TZUTC 1300 to be correct, but since its generated from a script Paul might have 1200 hard coded.

I'll also take a look at using the packet date as you mentioned in
a previous message. Maybe that would be a better choice than what I'm doing.. but again, I think I might just be over thinking this. :)

I dont recall what you are doing - but keep in mind, that the packet date I generate will be the time of the youngest message in the packet, in the time the source gave it to me (if the packet format has timestamps - from memory its only 2.2 that doesnt).


...ëîåï
--- SBBSecho 3.23-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On 14 Dec 2024 at 09:29p, deon pondered and said...

One of the things I can do - which I've toyed with in the past, is to
give packets (and possibly messages headers) in your local time. IE:
When we connect, and I get a NUL Date message, with timezone
information, by definition I know what timezone you are in and as I generate packets I can use that timezone for the packet header and
message headers.

does that mean I don't get to live in the future ...erm in the future :)

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 23 Dec 2024 at 07:23p, slacker pondered and said...

I think coming from hub 1, the TZUTC offset should be 1300 now instead
of 1200 for daylight savings, right? If I corrected for 1300, the time would have been valid and just 5 min before the current UTC time when I processed the packet.

you're correct 1/100 UTC should be +1300 at the moment, apologies for this if it's not.

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 24 Dec 2024 at 10:02a, deon pondered and said...

Yes, you are correct. I just looked at the packet I received from Hub 1,and it does have TZUTC 1200. It should be TZUTC 1300 to be correct,
but since its generated from a script Paul might have 1200 hard coded.

My bad this is exactly what is happening... Humm... how to best fix? I can manually edit this to fix for now... but it's a pain to have to change twice yearly... Oh well :)

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 27 Dec 2024 at 02:06p, Avon pondered and said...

My bad this is exactly what is happening... Humm... how to best fix? I
can manually edit this to fix for now... but it's a pain to have to

..and it's done, the next bunch of reports should show +1300

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Re: Re: FTN Packet's message date question
By: Avon to deon on Fri Dec 27 2024 02:06 pm

Howdy,

Yes, you are correct. I just looked at the packet I received from Hub 1,and it does have TZUTC 1200. It should be TZUTC 1300 to be correct, but since its generated from a script Paul might have 1200 hard coded.

My bad this is exactly what is happening... Humm... how to best fix? I can

"date +%z" should fix it for you. :)



...ëîåï
--- SBBSecho 3.23-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

Re: Re: FTN Packet's message date question
By: deon to Avon on Fri Dec 27 2024 09:36 pm

Howdy,

"date +%z" should fix it for you. :)

And in case you need it (cant remember if the + is allowed in the TZUTC kludge), "date +%z:cut -c2-" (where : is a pipe symbol).


...ëîåï
--- SBBSecho 3.23-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

And in case you need it (cant remem
ber if the + is allowed in the TZUT
C kludge), "date +%z:cut -c2-" (whe
re : is a pipe symbol).

*Pushes up glasses and does best 'nerd' voice* lol

According to fsp-1001.002, the '+' shouldn't be included but it notes that 'robust implementations should be prepared to find (and ignore) a plus if it exists.'

Btw Avon, your changes look good on my end from what I can tell. I don't see any error messages for TZ 1200 anymore in my logs.



--- NE BBS v0.76 (linux; x64)
* Origin: NE BBS - nebbs.servehttp.com:9223 (21:3/193)