On Saturday, February 23, 2019 at 11:30 PM, Maurice Kinal (2:280/464.113) wrote :

TO: Eric Pareja

Kamusta Eric!

@PID: WWIV 5.3.0.development
@TID: WWIV NET51.development
@MSGID: 3:633/408.1 0000001C
@CHRS: CP437 2
@TZUTC: +0800

Excellent TZUTC. The best I have ever seen. Way to go.

I just looked up FTS-4008.002 and it appears that the + shouldn't be there.

I'll file an issue on the WWIV tracker.

Salamat!

Eric

--- WWIVToss v.1.50
* Origin: Aliens' Alcove 2, Taguig, Philippines (3:633/408.0)

Kamusta Eric!

I just looked up FTS-4008.002 and it appears that the + shouldn't
be there.

FTS-4008.002 is wrong about this issue. According to the real world standard for utc offsets your's is correct. Dropping the + corrupts the actual offset and is *never* acceptable behavior on real networks, especially international ones.

I'll file an issue on the WWIV tracker.

I'd be very interested in what the discussion there will be on this issue. As I see it your utc offset was perfect. It is the FTSC that is wrong. Just look up utc offsets on the internet and you will see that dropping the + character is a HUGE no-no. Not posting one, as you are now doing, is a much better idea than corrupting your own data.

Maganda ang buhay,
Maurice

... Isang Møøse isang beses ang aking kapatid na babae ...
--- GNU bash, version 5.0.2(1)-release (aarch64-raspi3b+-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hi! Eric,

On 04 Mar 19 14:26, Maurice Kinal wrote to you:

I just looked up FTS-4008.002 and it appears that the + shouldn't
be there.

FTS-4008.002 is wrong about this issue. According to the real world standard for utc offsets your's is correct.

You are correct. Maurice mistakenly refuses to accept that Fidonet can and will set its own standards, in the form of FTSC issues.

Cheers,
Paul.

... Only those who attempt the absurd achieve the impossible.
--- GoldED+/LNX 1.1.5-b20130515
* Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)

Hey Paul!

Maurice mistakenly refuses to accept that Fidonet can and will
set its own standards

Wrong. Maurice refuses to program obvious corrupt standards which is why the TZUTC in this reply deploys the offset which honours the inclusion of the - character for timezones west of prime meridian rather than drop the + from utc (+0000) which the clock here is actually set to. That way it doesn't cause grief for any of the time based applications used on the system, such as sorting based on datetime stamps. Also it can be used to compensate for the lame FTN datetime stamp by adding the REAL datetime stamp lovingly called RFC-3339 (in nanoseconds) and can be used in a proper sort whereas your TZUTC will cause a failure as demonstrated below;

-={ '<Esc>:read !TZ=UTC date --rfc-3339=ns --date="05 Mar 19 09:13:00 1000"' starts }=-
date: invalid date ‘05 Mar 19 09:13:00 1000’
-={ '<Esc>:read !TZ=UTC date --date="05 Mar 19 09:13:00 1000"' ends }=-

Now had you put in a proper (correct) utc offset string then this will happen;

-={ '<Esc>:read !TZ=UTC date --rfc-3339=ns --date="05 Mar 19 09:13:00 +1000"' starts }=-
2019-03-04 23:13:00.000000000+00:00
-={ '<Esc>:read !TZ=UTC date --rfc-3339=ns --date="05 Mar 19 09:13:00 +1000"' ends }=-

The above can be compared to other msg's to determine their proper place in an archive as opposed to the current, obviously lame FTN datetime stamp along with it's corrupted utc offset.

BTW your FTN datetime stamp looks fudged. ;-)

Life is good,
Maurice

... A Møøse once bit my sister ...
--- GNU bash, version 5.0.2(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hi! Maurice,

On 04 Mar 19 16:52, you wrote to me:

The above can be compared to other msg's to determine their proper
place in an archive as opposed to the current, obviously lame FTN
datetime stamp along with it's corrupted utc offset.

Your arguments are wasted on me. I don't possess the smarts to decipher the whoosiemahjiggers. Why don't you figure out how to amend the FTS.

BTW your FTN datetime stamp looks fudged. ;-)

I'm glad you noticed.[sfx: blushing]

Cheers,
Paul.

... Hello ... Incontinence Hotline.' 'Can you hold, please?
--- GoldED+/LNX 1.1.5-b20130515
* Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)

Hey Paul!

Your arguments are wasted on me.

Probably but then again I saw the need to defend myself so it really doesn't matter ... does it?

I don't possess the smarts to decipher the whoosiemahjiggers.

And yet you seem to know what Maurice thinks about the FTSC and it's rights to creating standards, as well as my opinion and modus operendi as it pertains to all things called standards in this fine and upstanding hobby. What is the deal with that?

Why don't you figure out how to amend the FTS.

I've tried and may try again in the near future. It won't take much to rectify the current documentation in question and given they, whoever 'they' were and are, are only one character away from altering a pirated and corrupted standard to make it truly useful. Heck one might actually believe it is an achievable and honourable goal.

Speaking of FTN standards, why is your CHRS kludge using a bogus setting? Shouldn't it be "UTF-8 4"? Also I see no evidence that your editor can even handle utf8, nevermind type 4 utf8 characters ... whatever they are. Do you know?

Life is good,
Maurice

... A Møøse once bit my sister ...
--- GNU bash, version 5.0.2(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hi! Maurice,

On 03/05/2019 02:18 PM, you wrote:

And yet you seem to know what Maurice thinks about the FTSC and it's rights to creating standards, as well as my opinion and modus operendi
as it pertains to all things called standards in this fine and
upstanding hobby. What is the deal with that?

I lurk, and have noted your engagements with )\/(ark Lewis over this and other FTSC-related matters.

Why don't you figure out how to amend the FTS.

[... trimmed ...]

Heck one might actually believe it is an achievable and honourable
goal.

If you truly understood how the FTS might be amended you would realize the impossibility of doing so.

Speaking of FTN standards, why is your CHRS kludge using a bogus
setting? Shouldn't it be "UTF-8 4"? Also I see no evidence that your editor can even handle utf8, nevermind type 4 utf8 characters ...
whatever they are. Do you know?

I really don't give a damn.

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Cogito sumere potum alterum. (3:640/1384.125)

On 2019 Mar 04 14:26:28, you wrote to Eric Pareja:

@RFC-3339: 2019-03-04 22:26:28.754540249+00:00
@LANG: tl_PH.utf8
@MøøSGID: 2:280/464.113 5c7da614-2cf95ed9
Kamusta Eric!

I just looked up FTS-4008.002 and it appears that the + shouldn't
be there.

FTS-4008.002 is wrong about this issue.

once again, no, it is not... it is a fidonet specification... not an internet one... please stop confusing the two... it is extremely old and tiring, maurice :(

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... The wishbone will never replace the backbone!
---
* Origin: (1:3634/12.73)

Hey mark!

FTS-4008.002 is wrong about this issue.

once again, no, it is not...

Once again, yes, it is...

it is a fidonet specification...

If it is then it has been pirated and corrupted. The actual utc offset ***REQUIRES*** either a + or a - character at the start of the string depending on the specific timezone being expressed no matter what some lame FTS has to say about it.

not an internet one...

Agreed. However any implimentation I have seen on the internet deploys the +|- character such as defined in such programming functions as strftime(). They appear to have adopted the spec for utc offsets as it was designed by the people who truly understand these sorts of things. The US Navy comes to mind when thinking about an organization that had/has major influence on such matters.

please stop confusing the two...

I would NEVER do that.

it is extremely old and tiring, maurice :(

I don't recall asking you. You could have easily ignored this. I wouldn't have minded any.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.0.2(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

On 2019-03-04 15:55:17 +0000, Eric Pareja -> Maurice Kinal said:

I just looked up FTS-4008.002 and it appears that the + shouldn't be there.

I'll file an issue on the WWIV tracker.

Sorry for a late response, been on the road all week...

Actually that would be incorrect. For ISO standards on UTC, the use of + is only required due to the fact it is appended directly to the end of the seconds. Otherwise a 0500 appended to 11:30:22 would make a mess of parsers "guessing"... for example 11:30:22500 and 11:30:220500 are invalid. 11:30:22+0500 is correct.

However, you also cannot use "+" should be there because another platform uses it. I spent 20+ years making a living developing to RFC standards, and thus my interest in FTSC... to try and help. FTSC is much easier to read, the challenge is conflicting specifications... even in the current documents.

FYI: ISO 8601 did not state the "+" as required in section 3.4.2 prior to the 2004 edition of the standard. And FTSC-4008 was written prior to 2004 also, and for our platform (FTSC) it's rules govern our platform not vise versa.

Ozz

--- FMail-W32 2.0.1.4
* Origin: Modern Pascal, LLC. (1:275/362.0)

On 2019-03-05 04:18:33 +0000, Maurice Kinal -> Paul Quinn said:

Speaking of FTN standards, why is your CHRS kludge using a bogus
setting? Shouldn't it be "UTF-8 4"? Also I see no evidence that your
editor can even handle utf8, nevermind type 4 utf8 characters ...
whatever they are. Do you know?

Hey Maurice,

"Level 4 is for multi byte character encodings. The only presently
known implementation is UTF-8." .... fts-5003.001

If NNTPd supported it, I would paste in ExchangeBBS' UTF matrix, which does a full CP437->UTF-8 output for terminals it detects support UTF8. I spent months building it as Wikipedia's CP437 html uses invalid UTF-8 codes to represent the high-bit DOS character set.

^ACHRS: <identifier> <level>

--- FMail-W32 2.0.1.4
* Origin: Modern Pascal, LLC. (1:275/362.0)

On 2019 Mar 09 03:09:28, you wrote to Eric Pareja:

I just looked up FTS-4008.002 and it appears that the + shouldn't be
there.

I'll file an issue on the WWIV tracker.

Sorry for a late response, been on the road all week...

Actually that would be incorrect. For ISO standards on UTC,

there's the problem, though... fidonet is not using ISO standards... fidonet uses fidonet standards... some people just cannot seem to wrap their heads around this fact...

the use of + is only required due to the fact it is appended directly
to the end of the seconds. Otherwise a 0500 appended to 11:30:22 would make a mess of parsers "guessing"... for example 11:30:22500 and 11:30:220500 are invalid. 11:30:22+0500 is correct.

while this is true, fidonet uses the TZUTC control line to store the UTC offset so there is no confusion like you describe... numbers without a sign are positive and the only sign used is the '-' which easily indicates a negative...

However, you also cannot use "+" should be there because another
platform uses it. I spent 20+ years making a living developing to RFC standards, and thus my interest in FTSC... to try and help. FTSC is
much easier to read, the challenge is conflicting specifications...
even in the current documents.

reading this, i thing we're saying the same thing...

FYI: ISO 8601 did not state the "+" as required in section 3.4.2 prior
to the 2004 edition of the standard. And FTSC-4008 was written prior
to 2004 also, and for our platform (FTSC) it's rules govern our
platform not vise versa.

exactly! thank you!

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... If you're on thin ice, you might as well dance. - Anon
---
* Origin: (1:3634/12.73)

Здрастуйте Ozz!

ExchangeBBS' UTF matrix, which does a full CP437->UTF-8 output
for terminals it detects support UTF8.

Try this reply which contains valid utf8 characters in a language that is supported by fts-5003.001. I am betting it won't work. Also CP437 lacks some well used latin1 characters such as 'ø' that is vital in a well used tagline, "A Møøse once bit my sister ...", or the Old English saying, "Hwilum æfter medo menn mæst geþyrsteð." Also I fail to see what difference the level thingy is going to make in any application, including ExchangeBBS. An example of it's usage might be handy.

I spent months building it as Wikipedia's CP437 html uses invalid
UTF-8 codes to represent the high-bit DOS character set.

None of that surprises me. Have you tried glibc's iconv?

Життя чудове,
Maurice

... Не плач за мене у мене є vi.
--- GNU bash, version 5.0.2(1)-release (aarch64-raspi3b+-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hey Ozz!

Wikipedia's CP437 html uses invalid UTF-8 codes to represent the
high-bit DOS character set.

Here is something I slapped together on the commandline;

-={ '<Esc>:read cp437-utf8.codes' starts }=-
80 - 8f: c387 c3bc c3a9 c3a2 c3a4 c3a0 c3a5 c3a7 c3aa c3ab c3a8 c3af c3ae c3ac c384 c385
90 - 9f: c389 c3a6 c386 c3b4 c3b6 c3b2 c3bb c3b9 c396 c396 c39c c2a2 c2a3 c2a5 e282a7 c692
a0 - af: c3a1 c3ad c3b3 c3ba c3b1 c391 c2aa c2ba c2bf e28c90 c2ac c2bd c2bc c2a1 c2ab c2bb
b0 - bf: e29691 e29692 e29693 e29482 e294a4 e295a1 e295a2 e29596 e29595 e295a3 e29591 e29597 e2959d e2959c e2959b e29490
c0 - cf: e29494 e294b4 e294ac e2949c e29480 e294bc e2959e e2959f e2959a e29594 e295a9 e295a6 e295a0 e29590 e295ac e295a7
d0 - df: e295a8 e295a4 e295a5 e29599 e29598 e29592 e29593 e295ab e295aa e29498 e2948c e29688 e29684 e2968c e29690 e29680
e0 - ef: ceb1 c39f ce93 cf80 cea3 cf83 c2b5 cf84 cea6 ce98 cea9 ceb4 e2889e cf86 ceb5 e288a9
f0 - ff: e289a1 c2b1 e289a5 e289a4 e28ca0 e28ca1 c3b7 e28988 c2b0 e28899 c2b7 e2889a e281bf c2b2 e296a0 c2a0
-={ '<Esc>:read cp437-utf8.codes' ends }=-

Note that the utf8 codes are hex codes instead of the usual utf8 codes which I think makes it handier to match is what is seen in hex editors that DOS-think people enjoy using for such things. To actually print the character to the screen on a capable terminal one only has to do something like this;

-={ '<Esc:read !echo -e "\xc3\x87 is the same as \u00c7 and is 0x80 in CP437"' starts }=-
Ç is the same as Ç and is 0x80 in CP437
-={ '<Esc:read !echo -e "\xc3\x87 is the same as \u00c7 and is 0x80 in CP437"' ends }=-

If you'd prefer 'standard' utf8 codes it shouldn't be too much of a hassel to convert the above table to suit. Let me know as I know someone else in fidonet who might benefit from this type of conversion table.

It's a start.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.0.2(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hey Ozz!

Wikipedia's CP437 html uses invalid UTF-8 codes to represent the
high-bit DOS character set.

For the record do you mean https://en.wikipedia.org/wiki/Code_page_437 ?

I checked a few against the table I posted and so far noticed that 0x81, 0x82, and 0x83 show the proper characters as well as correct utf8 code BUT display the wrong hex code when highlighting the character in question. Near as I can tell thus far - and I don't plan to go any further with this since I have no use for this information - the table I posted shows the correct hex codes and do match the proper utf8 codes unlike the table https://en.wikipedia.org/wiki/Code_page_437 where at least three of the hex codes are obviously wrong when compared to what the actual character displayed and the posted utf8 code for that character.

Let me know if this is a worthwhile pursuit as near as I can tell it is of zero consequence in the grand scheme of things, nevermind fidonet and definetly the bogus CHRS kludge. :::evil grin:::

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.0.2(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

On 2019-03-09 12:37:34 +0000, mark lewis -> Ozz Nixon said:

reading this, i thing we're saying the same thing...

Exactly...

ON> FYI: ISO 8601 did not state the "+" as required in section 3.4.2 prior
ON> to the 2004 edition of the standard. And FTSC-4008 was written prior
ON> to 2004 also, and for our platform (FTSC) it's rules govern our
ON> platform not vise versa.

exactly! thank you!

No problem. I have been working on the FTSC specifications top to bottom and back... I have been finding/collecting topics I want to start presenting come Monday.

Ozz

--
+++ Are we having fun yet? I am!
ATZ|ATDT911|1,2~555

--- FMail-W32 2.0.1.4
* Origin: ExchangeBBS WHQ (1:275/362.0)

On 2019-03-10 01:05:44 +0000, Maurice Kinal -> Ozz Nixon said:

Hey Ozz!

ON> Wikipedia's CP437 html uses invalid UTF-8 codes to represent the
ON> high-bit DOS character set.

Here is something I slapped together on the commandline;

Note that the utf8 codes are hex codes instead of the usual utf8 codes
which I think makes it handier to match is what is seen in hex editors
that DOS-think people enjoy using for such things. To actually print
the character to the screen on a capable terminal one only has to do something like this;

It's a start.

Thanks, I have builtbasically the same. I do not use "C" unless I am porting "C" back to Pascal. I also noticed (this editor, Unison for Mac) does time wrong (per original subject topic)... ISO and RFC state not to use +0000, should use "Z" to avoid RgeExpr errors.

Thanks again! Nice to note another person contributing answer(s) instead of arguing to argue ;-)

Ozz

--
+++ Are we having fun yet? I am!
ATZ|ATDT911|1,2~555

--- FMail-W32 2.0.1.4
* Origin: ExchangeBBS WHQ (1:275/362.0)

Hey Ozz!

ISO and RFC state not to use +0000, should use "Z" to avoid
RgeExpr errors.

I am not sure I follow. Here are three examples I have for --iso-8601, --rfc-email and --rfc-3339 using coreutils's date app on linux;

date --iso-8601=seconds; 2019-03-10T00:47:36+00:00
date --rfc-email; Sun, 10 Mar 2019 00:47:36 +0000
date --rfc-3339=seconds; 2019-03-10 00:47:36+00:00

Note that all have the + character which I believe is correct for UTC. Personally I'd avoid --rfc-email given the output string is in English. All three formats convert fine to PST8PDT;

TZ=PST8PDT date --date="2019-03-10T00:47:36+00:00"; Sat Mar 9 16:47:36 PST 2019
TZ=PST8PDT date --date="Sun, 10 Mar 2019 00:47:36 +0000"; Sat Mar 9 16:47:36 PST 2019
TZ=PST8PDT date --date="2019-03-10 00:47:36+00:00"; Sat Mar 9 16:47:36 PST 2019

For purely %Z as per strftime() output this works;

date +%Z; UTC

For the record I still maintain that +00:00 or +0000 or even +00 is not a number. It is a string. Some people, no names mentioned (mark lewis), seem to be misguided into believing that it is a number.

Nice to note another person contributing answer(s) instead of
arguing to argue

Aw. You're no fun anymore.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.0.2(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

On 2019 Mar 10 00:34:56, you wrote to Ozz Nixon:

For the record I still maintain that +00:00 or +0000 or even +00 is not a number. It is a string. Some people, no names mentioned (mark lewis), seem to be misguided into believing that it is a number.

i don't know where you got that from but it is not totally correct... it will be a number at some point to be able to do the math needed...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Am I bugging you? Good!
---
* Origin: (1:3634/12.73)

Hey mark!

don't know where you got that from but it is not totally correct

From you in a prior messages, the latest being to Ozz stating, and I qoute;

while this is true, fidonet uses the TZUTC control line to store
the UTC offset so there is no confusion like you describe...
numbers without a sign are positive and the only sign used is
the '-' which easily indicates a negative...

The above is very similar to prior statements you have made about the TZUTC control line.

it will be a number at some point to be able to do the math
needed...

An example usage would great. Something like this that I would use for the message I am replying to;

date --date="10 Mar 19 10:25:00 -0400" = Sun Mar 10 14:25:00 UTC 2019

However in that case it doesn't show the conversion to a number(s), which I would assume to be unixseconds, which is indeed a number representing seconds.

date --date="10 Mar 19 10:25:00 -0400" +%s = 1552227900
date --date="@1552227900" = Sun Mar 10 14:25:00 UTC 2019

I could compilcate the above by writing a program to use strftime() but I doubt it would be better than the above examples using coreutils' date.

Every available source I have seen never bothers to correct for utc offsets, nevermind displaying the offset so that a reader can determine that the displayed message originated in a different timezone. If you know different I'd appreciate hearing about it but from everything I have seen thus far the TZUTC does absoultely nothing and is wrong given the lack of the + character where applicable.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.0.2(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

On 2019 Mar 10 16:24:58, you wrote to me:

don't know where you got that from but it is not totally correct

From you in a prior messages, the latest being to Ozz stating, and I

qoute;

while this is true, fidonet uses the TZUTC control line to store
the UTC offset so there is no confusion like you describe...
numbers without a sign are positive and the only sign used is
the '-' which easily indicates a negative...

The above is very similar to prior statements you have made about the

TZUTC

control line.

and the problem is???

it will be a number at some point to be able to do the math needed...

An example usage would great. Something like this that I would use for

the

message I am replying to;

date --date="10 Mar 19 10:25:00 -0400" = Sun Mar 10 14:25:00 UTC 2019

However in that case it doesn't show the conversion to a number(s), which

I

would assume to be unixseconds, which is indeed a number representing seconds.

exactly... the numeric string representation must be converted to a number for the math... the tools you are using are doing that behind the scenes :shrug:

date --date="10 Mar 19 10:25:00 -0400" +%s = 1552227900
date --date="@1552227900" = Sun Mar 10 14:25:00 UTC 2019

I could compilcate the above by writing a program to use strftime() but I doubt it would be better than the above examples using coreutils' date.

one ""problem"" here is that you are using RFC-oriented tools... they do not work like FTN tools do so you are forced to either 1) convert their output as needed or 2) complain about one side or the other not being ""done properly""...

Every available source I have seen never bothers to correct for utc offsets, nevermind displaying the offset so that a reader can determine that the displayed message originated in a different timezone.

your horizon is rather limited, though... anyone reading your posts for any real length of time can see that...

If you know different I'd appreciate hearing about it but from
everything I have seen thus far the TZUTC does absoultely nothing and

i've used TZUTC specifically to display times in the local-to-the-bbs timezone... there have been comments about how can a message be written in the future but when it is pointed out that the message originated in Oz and is 12 or so hours ahead of new york, then it makes sense... not all systems do this and there may very well be no indication that timezone conversion is even being
done... if the software you use and have seen hasn't made use of TZUTC, that's
an implementation problem... or not if they don't care to use it and simply display the time stamps as given...

is wrong given the lack of the + character where applicable.

again, you are stuck in non-FTN mode...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Some people pay a compliment as if they expected a receipt.
---
* Origin: (1:3634/12.73)

Hey mark!

one ""problem"" here is that you are using RFC-oriented tools...

No I am not. I already have stated many times that it is strftime() based which can and is being used to create RFC compatible datetime strings but can also create obsolete ftn datetime strings;

date +"%d %b %y %T" = 10 Mar 19 18:24:42

they do not work like FTN tools

What FTN tools? I am still waiting for a working example of something that gets it 'right' according to the fts-4008.002.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.0.2(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

On 2019-03-10 23:20:19 +0000, Maurice Kinal -> mark lewis said:

Hey mark!

ml> one ""problem"" here is that you are using RFC-oriented tools...

No I am not. I already have stated many times that it is strftime()
based which can and is being used to create RFC compatible datetime
strings but can also create obsolete ftn datetime strings;

date +"%d %b %y %T" = 10 Mar 19 18:24:42

ml> they do not work like FTN tools

What FTN tools? I am still waiting for a working example of something
that gets it 'right' according to the fts-4008.002.

Coming soon... since I am writing everything here from the bottom up - part of the Nodelist name decision for me 2 years ago "Fido Support". I want to build test cases, code, systems to test against - so new developers get from our platform what they are used to finding available on the Internet platform. Even if I have to code our examples for multiple languages (which is something I always thought FTSC and old RFC should have done).

Like your date example, making it along with others available in the same document. In the Pascal world we have FormatDatetime('DD mmm YY HH:NN:SS',Now). In Python we have datetime.datetime.now().strftime("%d %b %y %T") // Thanks to you showing me %T

--- FMail-W32 2.0.1.4
* Origin: ExchangeBBS WHQ (1:275/362.0)

Hey Ozz!

Coming soon...

:::shudder:::

Why bother? If there is not a current and/or past application then what is the purpose of creating one that obviously is flawed and will introduce bugs given the corrupt offsets for at least half of the offsets listed in fts-4008.002? Wouldn't it be more prudent to correct that documentation and use strftime's supported %z that honours the original intent of offsets in the first place? It seems to me that this is the PERFECT opportunity to right a past wrong.

In the Pascal world we have FormatDatetime

I noticed that when doing a search the other day. Not bad but strftime() is better methinks.

In Python we have datetime.datetime.now().strftime("%d %b %y %T")

Also perl, php, c, c++, ruby, etc. Has been for ages. Too bad pascal cannot keep up with the (strf)times eh? ;-)

Thanks to you showing me %T

See http://man7.org/linux/man-pages/man3/strftime.3.html for all the specifiers. They should be the same for all languages/interpreters/scripter. The coreutils date runtime also includes a few switches for compatibilty with certain formats such as --iso-8601 which is not in strftime() but can easily be reproduced with the correct specifiers. Piece of cake ... including the obsolete FTN datetime stamp. ;-)

However %z will ALWAYS output the + character where applicable such as in UTC based systems;

date +%z = +0000

You will have to add a routine to strip it which will break other apps that follow the real world standards for utc offsets. Whoever wrote fts-4008.002 should hang their head in shame. :::sigh:::

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.0.2(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

On 2019-03-12 01:43:39 +0000, Maurice Kinal -> Ozz Nixon said:

However %z will ALWAYS output the + character where applicable such as
in UTC based systems;

date +%z = +0000

You will have to add a routine to strip it which will break other apps
that follow the real world standards for utc offsets. Whoever wrote fts-4008.002 should hang their head in shame. :::sigh:::

See we can not say that, as the ISO standard also had "+" as optional, until it was revised in 2004. Both our FTSC standard and the ISO standard were the same. Obviously someone out there did not understand if no "-" minus sign is included then assume positive. I know it is hard to understand ... but like accounting, we only denote negative, positive is assumed.

;-)

O.

// Almost have this NNTPD environment fully automated ;-)

--- FMail-W32 2.0.1.4
* Origin: ExchangeBBS WHQ (1:275/362.0)

Hey Ozz!

See we can not say that, as the ISO standard also had "+" as
optional, until it was revised in 2004.

References please. I've never seen any mention of the + as an option in any official documentation of utc offsets and in fact have seen the opposite including that UTC (+0000) is to include a + sign despite it not being behind or ahead of UTC (ISO 8601). Another reference worthy of mention is https://en.wikipedia.org/wiki/List_of_UTC_time_offsets which is worth comparing to the list in fts-4008.002. The only reference to 2004 I see as far as ISO 8601 is concerned is as follows (and I quote);

The section dictating sign usage (section 3.4.2 in the 2004 edition
of the standard) states that a plus sign must be used for a
positive or zero value, and a minus sign for a negative value.
Contrary to this rule, RFC 3339, which is otherwise a profile of
ISO 8601, permits the use of "-00", with the same denotation as
"+00" but a differing connotation.

If you could please provide further evidence of an ISO, or RFC, prior to 2004 that states the + character is optional I'd appreciate it. However I doubt it will change anything given the current state of well used modern dating applications that insist on displaying the + character when and where it is applicable. As for the above quote, and if my ageed memory serves me correct, the "differing connotation" is a - character can be used in UTC when it is converted from a different timezone other than UTC itself.

date --iso-8601=seconds = 2019-03-12T21:35:03+00:00
date --rfc-3339=seconds = 2019-03-12 21:36:50+00:00

From the above it looks to me that both standards are in sync wrt the display of utc with a + character. Also worthy of note is the : character to delimit hours from minutes in the offset. To make that work it has to use the %:z specifier, or even %::z to include seconds, as shown below;

date +%:z = +00:00
date +%::z = +00:00:00

Put *THAT* in your corrupted fts-4008.002 standard and rotate! :::evil grin:::

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.0.2(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

On 2019-03-13 01:44:42 +0000, Maurice Kinal -> Ozz Nixon said:

comparing to the list in fts-4008.002. The only reference to 2004 I
see as far as ISO 8601 is concerned is as follows (and I quote);

The section dictating sign usage (section 3.4.2 in the 2004 edition
of the standard) states that a plus sign must be used for a

Well, in your quote - you point to the statement in general that 3.4.2 was revised in 2004 to state "must"... prior to the 2004 revision, the word "must" did not exist.

-- now, I am not fighting for or against, I am simply on Marks side
about - it is not referencing the same material or format. Material in question, is FTSC not RFC, nor ISO, but F.T.S.C. *love evil grins, and applying one here* ... next. for the "Format". The requirement for the + denotion is when concatenating TZ to existing string, it needed something to denote it is not HH:MM, but ZH:ZM (Zone Hour, Zone Minutes - prefix +/- to help parsers and humans that would have had a heart attack to see 11:39:28 03:00, or worse 03:00:00 03:00)... I can just hear the explosions in EEST right now ... of the heads parsing that sentence). ;-P'"'"'"'"'

Per F.T.S.C. we are denoting a Kludge line ... TZUTC, with the range of 1400..-1100 (LINT to NUT)... yeah, I could not have came up with funnier timezone initials for this post if I tried (a US religious joke, during LINT you would not use the phrase NUT or anything to imply sexual or curse phrases).

--- FMail-W32 2.0.1.4
* Origin: ExchangeBBS WHQ (1:275/362.0)

Hey Ozz!

you point to the statement in general that 3.4.2 was revised in
2004 to state "must"

Which only applied to UTC. Before 2004 it could also be a - character as in -0000 or -00, whereas after 2004 it became "must" be a + character which means +0000 or +00 and NEVER -0000 or -00. All other timezones were either + or - depending whether they were ahead (+) or behind (-) UTC.

I am still waiting a reference where it states that dropping the + character is acceptable behavior as you state in "MSGID: 1:275/362.0 5c88111e" and I quote;

See we can not say that, as the ISO standard also had "+" as
optional, until it was revised in 2004. Both our FTSC standard
and the ISO standard were the same.

Please produce the evidence for the above or acknowledge it as bullshit which it now appears to be, especially in light of the quote offered in "MSGID: 2:280/464.113 5c881a3a" which was quoted from ISO 8601. You provide nothing in return to back up your above quoted statement. I sincerely doubt it's validity.

Material in question, is FTSC not RFC, nor ISO, but F.T.S.C.

Agreed. I have never disputed that fact. What I am stating, and have stated in the past, is that fts-4008.002 in particular is a highly faulty document that should have never seen the light of day and it's author should hang his head in shame. Also I recall stating that the concept of UTC offsets was pirated and corrupted or something along that line and have provided evidence to back my statement.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.0.2(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Re: Re: Re TZUTC
By: Ozz Nixon to mark lewis on Sat Mar 09 2019 04:19 pm

No problem. I have been working on the FTSC specifications top to bottom and back... I have been finding/collecting topics I want to start presenting come Monday.

Grin, reminds me need to know if you want the private echo from me or Andrew. I was going to ask him but he netmailed first that it was ok if you wanted it from here.

Let me know? I have to turn it on manually here but it takes only a few seconds.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS, shenks.synchro.net (1:275/100)

On 2019-03-14 00:13:38 +0000, Carol Shenkenberger -> Ozz Nixon said:

Re: Re: Re TZUTC
By: Ozz Nixon to mark lewis on Sat Mar 09 2019 04:19 pm

ON> No problem. I have been working on the FTSC specifications top to

bottom

ON> and back... I have been finding/collecting topics I want to start
ON> presenting come Monday.

Grin, reminds me need to know if you want the private echo from me or Andrew. I was going to ask him but he netmailed first that it was ok if you wanted it from here.

Let me know? I have to turn it on manually here but it takes only a few seconds.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS, shenks.synchro.net (1:275/100)

Go ahead and link me in - my system auto-adds anything from you. Unless there is a reason I should pull from Andrew? If so, no biggy I can add him - polling side is 100% debugged for unlimited uplinks. (I am still setting up my two downlinks - then I have to decide (point or not for them)).

Thank you!
Ozz

--- FMail-W32 2.0.1.4
* Origin: ExchangeBBS WHQ (1:275/362.0)

Re: Re: Re TZUTC
By: Ozz Nixon to Carol Shenkenberger on Wed Mar 13 2019 10:21 pm

Grin, reminds me need to know if you want the private echo from me or
Andrew. I was going to ask him but he netmailed first that it was ok
if you wanted it from here.

Let me know? I have to turn it on manually here but it takes only a
few seconds.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS, shenks.synchro.net (1:275/100)

Go ahead and link me in - my system auto-adds anything from you. Unless there is a reason I should pull from Andrew? If so, no biggy I can add him - polling side is 100% debugged for unlimited uplinks. (I am still setting up my two downlinks - then I have to decide (point or not for them)).

Thank you!

No problem, I'll have you linked in in a few minutes. Remember to mark it so it's you only and no one can AREAMGR add it. AREANAME: FTSC (the private one, the other is FTSC_PUBLIC). Andrew sent us a netmail that it was fine in this case to pull from me since I'm your NC.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS, shenks.synchro.net (1:275/100)

On 2019 Mar 13 22:21:52, you wrote to Carol Shenkenberger:

Go ahead and link me in - my system auto-adds anything from you.

please ensure that your default auto-add is not public access... this is how areas start leaking to individuals that should not have access...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... We must take certain liberties in the name of freedom.
---
* Origin: (1:3634/12.73)

Found this document, which also shows using simplified UTC, and "+" is dropped:

fsc-0084.001:
The UTC offset of the site that generated timestamp as described above
is stored in the utcoffset field. Eg: if the UTC offset is -0230, the
utcoffset field should read, simply, -230; +0200 => 200; and so forth.


--
.. Ozz Nixon
... Author ExchangeBBS (suite)
.... Since 1983 BBS Developer

--- FMail-W32 2.0.1.4
* Origin: ExchangeBBS WHQ (1:275/362.0)

On 2019 Mar 22 17:49:08, you wrote to me:

Found this document, which also shows using simplified UTC, and "+" is dropped:

fsc-0084.001:
The UTC offset of the site that generated timestamp as described above
is stored in the utcoffset field. Eg: if the UTC offset is -0230, the
utcoffset field should read, simply, -230; +0200 => 200; and so forth.

that's in the reference library for historical purposes... it was written in 1995 and is for EDX (Electronic Data eXchange)... other documents may have some parts derived from it but it is not in force in any way... there may be some systems that have implemented EDX but i'm not aware of any... a quick scan seems to indiate that it is kinda of another packet or packed message type... i remember reading it years back when it first came out but wasn't interested in it to any real point...

the documents that matter are FTS and FSP... FTS are standards whereas FSP are standards proposals... FSPs will never make it to standards if they are not implemented and ""widely used""... but just because there's not a standard or a proposal shouldn't prevent a developer from coming up with something new that works well and is ""widely used""... when that happens, someone will generally write a proposal documenting it... that someone may be the developer, another party interested in the thing or it may be written by the FTSC as a group project... as a proposal, it is then available for others to read and possibly implement without having to reverse engineer the thing or querying the developer of it... if something in the proposal is incorrect, it can be updated easily... the same for standards, too... they are not really set in stone like RFCs...

i forget what FSC stood for but IIRC they were proposals before the new format and naming conventions were adopted by the 2nd or 3rd FTSC... FSP is clearer than FSC for indicating a proposal... they are of interest to some folks but they are old documents...

something else is that software documentation generally states what standards and proposals it implements and supports... not all standards and proposals have to be implemented... an example of this is the two formats of TZUTC that are floating about... one is a standard... the other is not... the software implementing the other format does not state that it has implemented the TZUTC proposal or standard... granted, using a different control word would have been better but that wasn't done... i cannot say if one is better than the other, either... i only know that both are in the wild...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... tobaco free, soon YOU and me, what a wonderful way to be ;*)
---
* Origin: (1:3634/12.73)