MK> Just a little something to brighten your day and perhaps spark much MK> needed participation in this particular echoarea, or whatever the kids MK> are calling it these days.
MK> proposed DateTime = a string 19 bytes long. MK> Format = "YYYY-MM-DD hh:mm:ss" where, MK> YYYY = four digit year MK> MM = two digit month ranging from 01 MK> to 12 MK> DD = two digit day ranging from 01 to MK> 31 MK> hh = two digit hour ranging from 00 to MK> 23 MK> mm = two digit minute ranging from 00 MK> to 59 MK> ss = two digit second ranging from 00 MK> to 59
MK> Since there is no room for the UTC offset DateTime should be set to MK> UTC in order to avoid confusion. This format will ensure that the MK> packed message is exactly the same byte length as specified in MK> fts-0001.016 not counting the ASCII null charater that terminates the MK> string as per packed MSG header specification for all header strings MK> (eg To, From, subj, etc).
While I can see the merits of your proposal, it currently is not implemented in any FidoNet compatible software. Current FidoNet software that parses the DateTime field would need to be updated to support this new format. For compatibility with existing FidoNet software, implementations would need to be able to parse this format, or the 2 other existing formats (FTS-1 or SeaDog.) In addition, to avoid breaking existing software, this format should not be used in packets without confirming that the software on the other end can process it correctly.
Given that many software packages used in FidoNet have been abandoned, had their source code lost, or the authors are no longer available, it is not likely that this format will succeed.
Your best shot is to convince the maintainers of existing packages which are still being developed, such as HPT, D'Bridge, MBSEBBS, Synchronet, and Mystic of the merits of your proposal, and get it implemented. Several of these packages are open source, so you could conceivably implement it yourself and submit patches to the maintainers for consideration.
As for the use of UTC in packet headers, again you are fighting an uphill battle. The TZUTC kludge line was created because the .MSG and .PKT headers had no provision for timezone offsets.
