Subj : alternative DateTime (ref: fts-0001.016)
To : Maurice Kinal
From : Rob Swindell
Date : Sat Dec 19 2020 12:05 pm
Re: alternative DateTime (ref: fts-0001.016)
By: Maurice Kinal to Rob Swindell on Sat Dec 19 2020 09:02 am
> Hey Rob!
>
> RS> SBBSecho defaults to exporting type 2+ packets
>
> Okay I had a looksee at a pktheader parser I wrote awhile back and I now see
> that I was confusing 2+ with 2.2 so your statement above would put SBBSecho
> amongst the majority.
Earlier you stated "Most are 2.2 only and don't even know it.", so even allowing that you confused 2+ with 2.2, that's still not true of SBBSecho.
> All my links support type 2+ pkts while only one
> supports type 2, while another can do 2.2. So from my perspective both 2
> and 2.2 are equally rare.
The term "support" and "do" here are rather vague: those terms could refer to the production of packets of a particular type, the consumption of packets of a particular type, or a combination.
> RS> FidoNet (collectively) is vehemently opposed to anything that is
> RS> not interoperable with FidoNet software from the 80's or 90's.
>
> I wish I could say that them were the days but my heart wouldn't be in it.
> Everyone I knew from that time is no longer in the game and whatever
> software they were using back then has long since been abandoned even before
> y2k and the two digit year became real issues of concern. I am convinced
> that had the four digit year replaced the packed msg DateTime back in 1999
> or 2002 there would have been minimal problems with it.
<shrugs> If a new date/time format can be introduced in a backward-compatible manner, that's how it should be done, IMHO. And FidoNet should use an existing standard this time, stop making up new (badly defined) ones.
