Text 5361, 67 rader
Skriven 2012-04-25 19:28:49 av Rob Swindell (24986.ftsc_pub)
   Kommentar till text 5351 av Maurice Kinal (1:261/38.9)
Ärende: i got got got got no time
=================================
  Re: i got got got got no time
  By: Maurice Kinal to Alexey Vissarionov on Mon Apr 23 2012 08:38 pm

 > Hey Alexey!
 >
 > Current packed ftn DateTime msg header takes on the form of "23 Apr 12
 > 19:48:40" which not counting the NUL delimeter will always be 19 bytes.
 > The generated TZUTZ kludge in my case will always be 13 bytes which
 > includes the required 0x01 prefix and the 0x0d suffix.  In the case of a
 > negative utc offset it will be 14 bytes.  Beats me why they, whoever 'they'
 > are, would think dropping the '+' character was a good idea but there it
 > is.  Counting total bytes generating (or storing) the message costs a total
 > of 19 + 13 = 32 bytes, 33 bytes for negative people.
 >
 > Given the above example the ftn DateTime in rfc-3339 format will translate
 > to "2012-04-23 19:48:40+00:00" and will not require a TZUTC kludge since
 > the information is already there.  It costs exactly 25 bytes total and is
 > VASTLY more useful than the ftn method no matter how one looks at it,
 > nevermind the byte savings per msg.
 >
 > For example, suppose I recieve a msg from you in this echo with a ftn
 > DateTime of "24 Apr 12  01:10:38" and a TZUTC kludge showing 0400 which is
 > possible.  The rfc-3339 format magically becomes "2012-04-24
 > 01:10:38+04:00" once I convert it on my end.  In the new format the field
 > for DateTime is untouched and would be as shown (without the quotation
 > marks of course) and if I pump that value to my localtime then look what
 > happens;
 >
 >   # date --date="2012-04-24 01:10:38+04:00"
 >   Mon Apr 23 21:10:38 UTC 2012
 >
 > Neat eh?  You've magically been transformed into UTC time without any loss
 > to accuracy as well as leaving the field in the new format untouched so
 > that others with different utc offsets can do the same relative to their
 > date and time.
 >
 > I think rfc-3339 is a keeper.  How about you?

If you're going to adopt a different date/time format, I would recommend 
considering referencing ISO-8601 (the actual standard) rather than RFC-3339 (a 
proposed standard). In ISO-8601, the symbols (dashes and colons) are optionally

omitted.

I agree that the ISO-8601/RFC-3339 format is much better than the FTS-1 version

but it's unlikely to get wide adoption at this point. I still see so many 
messages withOUT a REPLY kludge, that I don't hold out a lot of hope for true 
improvement in the workings of FidoNet.

I actually introduced a new header format for QWK packets and used ISO-8601 for

the formatting of date/time header fields (written and imported), but I did so 
unilaterally and left the original (lame) date/time field intact - similar to 
your proposal for FTN.

Anyway, I think it's a good idea, but doesn't really add that much value over 
the combination of the other existing fields. For additional value, I think 
storing the date/time/zone the message was *written* separately from the 
date/time/zone the message was *imported* (potentially a different time) as 
separate fields is sometimes of value.

The reduction in storage (in bytes) is not a compelling argument today, 
especially since you'd have to retain the old fields for backwards 
compatibility anyway.
--- SBBSecho 2.13-Win32
 * Origin: Vertrauen - vert.synchro.net (1:103/705)