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.

.