Hello Axel,

>> Date: Sun, 23 Sep 2018 16:15:00 +1200

That +1200 against UTC/GMT is wrong here.
Central European Summer Time in The Netherlands and Germany is only
UTC/GMT +02:00.
So in that case my original message date should be 13:15 +00:00.
I have checked my BBS software and the TZ variable shows: TZ=CET-01CES
Unfortunately it is not transfered to a kludge in the messages.

>> I write this now at sunday 23rd sept.2018 15:15 (UTC/GMT+02:00)

> It looks all wrong. 4 pm is not 3 pm and the correct time stamp would
> have been:

> Mon, 24 Sep 2018 01:15:00 +1200

Why Monday?
It was written at sunday afternoon, 15 minutes past 3 o'clock.
01:15 is also wrong as that was not the UTC/GMT time I was writing.
The Netherlands has UTC/GMT+01:00 and because of summertime it is 1 hour later,
so that's why we have here UTC/GMT+02:00, same as you.
Note: BST (British SummerTime) = UTC/GMT+01:00.
So the Usenet time should be: Sun, 23 Sep 2018 03:15 +1200.
I think the + of - sign has UTC/GMT as a base setting.
So the software should convert local time of the writer to UTC/GMT,
in my case subtract 2 hours from it,
and than convert it to the local time of the gateway by adding that +1200.

May be a problem arises when that calculation has to change date also.
Suppose I wrote that message 4 hours earlier:
Then my time was 11:15 local, but 09:15 at real UTC/GMT.
Than his software would made it: Sat 22 Sep 2018 23:15 +1200 for usenet.
As 23:15 +12:00 gives 11:15 my original time.
Problably that day conversion is the hick we now have?
Then he doesnot change day, and indeed that is in future.

The difference between The Netherlands and NZ is only 10 hours in summer,
am I right?
I do not know if NZ has summertime (Daylight Saving Time) too?
So that hour difference between 15:15 and 16:15 can be explained by that?
At the end of Oktober You and I have no summertime any more.

So we still have to find a good way for converting date and times to a value
not causing messages in future, because that was the problem at some systems.

Every good programmer knows that you allways have to check the values at the
end sizes that can occur. So you have to try every date and time on every place
in the world compared to the local time the gateway is using.
And that has to be converterd to UTC/GMT with an offset to local.
That should be the writing time, not the converting time,
as the may differ ;-).

But then there is the problem that not al BBSsoftware packages show the time
zone in their msg's. So he does not know in what time zone that bbs resides.
But that can be find too. He knows the from nodenumber which is listed in the
FidoNet NodeList complete with a location. Then he only needs a table of
BBSplaces and their timezone compared to UTC/GMT.
Then he can calculate the time difference between the gateway station and that
BBS location.
Is that a workable way?

Henri.

---