Subj : alternative DateTime (ref: fts-0001.016)
To   : Maurice Kinal
From : Rob Swindell
Date : Sat Dec 19 2020 05:33 pm

  Re: alternative DateTime (ref: fts-0001.016)
  By: Maurice Kinal to Rob Swindell on Sun Dec 20 2020 12:52 am

 > Hey Rob!
 >
 >  RS> Which is to say: it would not work at all, in a backwards
 >  RS> compatible way.
 >
 > It is EXACTLY as backwards compatible as it needs to be, both for now as
 > well as back in 1995 and probably earlier.

I guess you don't know what "backwards compatible" means. Backwards compatible means it would continue to work with existing systems. Your proposal does not continue to work with existing systems.

 > Unless you can point to a currently running system, or even one back in
 > 1968, that required a two
 > digit year to function in order to achieve proper FTN based digital
 > communications,

All currently running systems using SBBSecho would reject packets that contain dates in your proposed format since the date format you propposed does not conform to the FTN specs. I suspect most other echomail programs would do the same.

 > then I will still maintain that the current proposal stands
 > and is indeed TRULY backwards compatible.  By you limited definition nothing
 > is backwards compatible including 8-bit systems that require a 2 digit year
 > for their punch card IO database.

Its not specifically the number of digits in the year that is the problem but rather that the various numeric fields are in a different order and at different offsets within the date/time string field.

 > Please feel free to fold, spindle and mutilate THAT.

Is this how you normally engage in technical discussions?

 >  RS> Continuing what?
 >
 > Living and learning.

Sure. I don't see the relevance.

.