Hi All,
I'm trying to make sure that I'm importing messages with the right date and time based on the message date as well as the TZUTC kludge. What I noticed is that not all messages have a TZUTC kludge and the date of the message is given in their local time.
I've also noticed that some messages have a TZUTC kludge but after adjusting the date of the message to UTC based on that, sometimes the date is still a little ahead of UTC. I'm guessing perhaps that one is just due to drifting origin BBS server times.
Anyone have an idea how to parse the date when no timezone info is given? Am I thinking to much about this and should just be using the date when I import the message into my BBS instead of the actual message's date?
When no timezone info is given, the best you can do is guess that it's either UTC or *your* local timezone. Unless you have some other way to know/guess the originator's timezone (nodelist maybe?).
Hi All,
Anyone have an idea how to parse the date when no timezone info is
given? Am I thinking to much about this and should just be using the
date when I import the message into my BBS instead of the actual
message's date?
Thanks!
Depending on what you are doing mailer wize, during a BINKP (and EMSI) ses sion, the remote's time is passed to you - from there you know their local
time, and I think you'd know whether it was UTC or local.
So in this case, it was hours ahead. Clearing Houz is +11 hours. Does that effect any of the packet times that are sent to me?
In this case, I'm download the packets from clearing houz for the echomail areas.
Here's the FTSC date from the packet:
FTSC_DATE: 14 Dec 24 03:01:22
So in this case, it was hours ahead. Clearing Houz is +11 hours. Does that effect any of the packet times that are sent to me?
FTSC_DATE: 14 Dec 24 03:01:22
So in this case, it was hours ahead. Clearing Houz is +11 hours. Does that effect any of the packet times that are sent to me?
With clrghouz, the packet date, is the date of youngest (most recent) message in the packet, in UTC.
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.
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.
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. :)
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.
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.
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
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. :)
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).
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 4 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 80:42:46 |
| Calls: | 66 |
| Calls today: | 1 |
| Files: | 21,500 |
| Messages: | 73,851 |