All,

Today I made the wrong assumption that a point's TZUTC-information would reflect the one from his boss.

It was made clear to me by Wilfred and Michiel that this does not have to be the case as a point might reside in a different time-zone than his boss.

TZUTC is discussed in FTS-4008.

I see it as an ambiguity, a minor one, but nevertheless that the situation of a point residing in a different time-zone is not explained and I would suggest that some wording is added to reflect this.

At the same time the wording...

"This document adopts the TZUTC control paragraph because is the shortest"

...could be changed to...

"This document adopts the TZUTC control paragraph because IT is the shortest"

...inserting the 'it'.

\%/@rd

--- DB4 - Oct 12 2021
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)

Ward wrote (2021-11-06):

All,

Today I made the wrong assumption that a point's TZUTC-information would reflect the one from his boss.

It was made clear to me by Wilfred and Michiel that this does not have to be the case as a point might reside in a different time-zone than his boss.

Really? And how is that important?

TZUTC is discussed in FTS-4008.

I see it as an ambiguity, a minor one,

FTS-4008 doesn't talk about nodes, bosses or points. It only talks about local time and the time zone for the message.

but nevertheless that the
situation of a point residing in a different time-zone is not explained and I would suggest that some wording is added to reflect this.

Why? A node (or a point) might even use different time zones in different messages. Some people do travel and write messages from different time zones. One might also choose to use a time zone in fidonet messages that doesn't reflect their physical location.

And then there are gateways (e.g. RFC<->FTN).

---
* Origin: 1995| Invention of the Cookie. The End. (2:280/464.47)

Hello Ward,

On Saturday November 06 2021 16:50, you wrote to All:

Today I made the wrong assumption that a point's TZUTC-information
would reflect the one from his boss.

It was made clear to me by Wilfred and Michiel that this does not have
to be the case as a point might reside in a different time-zone than
his boss.

TZUTC is discussed in FTS-4008.

I see it as an ambiguity, a minor one, but nevertheless that the
situation of a point residing in a different time-zone is not
explained

What is there to explain? The assumption that a point - or a user for that matter - resides in the same time zone as the boss or sysop is simply wrong. The TZUTC kludge serves to derive the UTC time the message was written from the time in the message header. This mechanism works without making any assumptions about the location of the writer of the message. I see no ambiguity and no need for explanation.

You know what our friends "across" say about ASSumptions?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Michiel,

You know what our friends "across" say about ASSumptions?

Empty barrels produce a lot of noise?

\%/@rd

--- DB4 - Oct 12 2021
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)

-={ 2021-11-07 03:18:44.130034325+00:25:21 }=-

Hey Ward!

"This document adopts the TZUTC control paragraph because IT is
the shortest"

Perhaps a little too short? How close is close enough?

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: One of us @ (1:153/7001.61453)

Hey Maurice!

@TZUTC: 0025

As of this reply the above should be "fixed" but we both know that isn't REALLY true. ;-)

Life is good,
Maurice

... Ní dhéanfadh an soal capall rasa d'asal
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: One of us @ (1:153/7001.61453)

As of this reply the above should be "fixed" but we both know that isn't REALLY true. ;-)

There's two of you ??
--- DB4 - Oct 12 2021
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)

Hey Oli!

You've made up your own time zone, which is perfectly valid.

It is valid and I didn't make it up. IANA is calling it "UTC+00:25:21" - Dunsink Observatory near Dublin - and before 1916 it was the official time for all of Ireland. It is still on the books as a valid timezone but as you can see above there are issues given the limitations of the TZUTC kludge (hhmm) and if used directly in time adjustments it will always be shy 21 seconds. It will be -0025 instead of -002521 but even that won't solve the problem since most datetime apps only use the hhmm (or hh:mm) format including fts-4008.002.

Btw, do I understand it correctly that the TZUTC for Iceland is
-0000?

From what I see in fts-4008.002 it would be 0000. Officially I believe Iceland uses UTC±00:00 with no DST. Both -0000 and +0000 yeild the exact same adjustment. 0000 will ALWAYS produce an error to any reasonable datetime application, following universally accepted standards that have been in use since forever.

I vote fts-4008.002 should be declared invalid and that a proper rfc-3339 datetime stamp be adopted in the msgHeader to replace the two digit datetime stamp.

Life is good,
Maurice

... Ní dhéanfadh an soal capall rasa d'asal
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: One of us @ (1:153/7001.61453)

Hey Ward!

There's two of you ??

I count five although a couple of me are really quiet (lurkers).

Life is good,
Maurice

... Ní dhéanfadh an soal capall rasa d'asal
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: One of us @ (1:153/7001.61453)

There's two of you ??

I count five although a couple of me are really quiet (lurkers).

Getting drunk then becomes expensive...

\%/@rd

--- DB4 - Oct 12 2021
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)

Hey Ward!

Getting drunk then becomes expensive...

For sure, especially considering *THEE* birthday.

Life is good,
Maurice

... Þæs ofereode, þisses swa mæg.
That passed away; so will this.
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: Little Mikey's EuroPoint @ (2:280/464.113)