REPLY: 1:275/362.0 5c95665c   
   MSGID: 1:3634/12.73 5c963653   
   PID: GED+LNX 1.1.5-b20180707   
   CHRS: CP437 2   
   TZUTC: -0400   
   TID: hpt/lnx 1.9.0-cur 07-09-15   
      
    On 2019 Mar 22 17:49:08, you wrote to me:   
      
    ON> Found this document, which also shows using simplified UTC, and "+" is   
    ON> dropped:   
      
    ON> fsc-0084.001:   
    ON>   The UTC offset of the site that generated timestamp as described above   
    ON>   is stored in the utcoffset field. Eg: if the UTC offset is -0230, the   
    ON>   utcoffset field should read, simply, -230; +0200 => 200; and so forth.   
      
   that's in the reference library for historical purposes... it was written in   
   1995 and is for EDX (Electronic Data eXchange)... other documents may have   
   some parts derived from it but it is not in force in any way... there may be   
   some systems that have implemented EDX but i'm not aware of any... a quick   
   scan seems to indiate that it is kinda of another packet or packed message   
   type... i remember reading it years back when it first came out but wasn't   
   interested in it to any real point...   
      
   the documents that matter are FTS and FSP... FTS are standards whereas FSP are   
   standards proposals... FSPs will never make it to standards if they are not   
   implemented and ""widely used""... but just because there's not a standard or   
   a proposal shouldn't prevent a developer from coming up with something new   
   that works well and is ""widely used""... when that happens, someone will   
   generally write a proposal documenting it... that someone may be the   
   developer, another party interested in the thing or it may be written by the   
   FTSC as a group project... as a proposal, it is then available for others to   
   read and possibly implement without having to reverse engineer the thing or   
   querying the developer of it... if something in the proposal is incorrect, it   
   can be updated easily... the same for standards, too... they are not really   
   set in stone like RFCs...   
      
   i forget what FSC stood for but IIRC they were proposals before the new format   
   and naming conventions were adopted by the 2nd or 3rd FTSC... FSP is clearer   
   than FSC for indicating a proposal... they are of interest to some folks but   
   they are old documents...   
      
   something else is that software documentation generally states what standards   
   and proposals it implements and supports... not all standards and proposals   
   have to be implemented... an example of this is the two formats of TZUTC that   
   are floating about... one is a standard... the other is not... the software   
   implementing the other format does not state that it has implemented the TZUTC   
   proposal or standard... granted, using a different control word would have   
   been better but that wasn't done... i cannot say if one is better than the   
   other, either... i only know that both are in the wild...   
      
   )\/(ark   
      
   Always Mount a Scratch Monkey   
   Do you manage your own servers? If you are not running an IDS/IPS yer doin' it   
   wrong...   
   ... tobaco free, soon YOU and me, what a wonderful way to be ;*)   
   ---   
    * Origin:  (1:3634/12.73)   
   SEEN-BY: 1/120 15/2 18/0 200 116/116 123/0 25 50 150 755 1970 135/300   
   SEEN-BY: 153/7001 7715 154/10 20 30 40 700 203/0 221/0 6 226/17 227/400   
   SEEN-BY: 229/107 426 452 1014 240/5832 249/206 317 400 261/38 280/464   
   SEEN-BY: 280/5003 310/31 317/3 322/757 340/800 342/200 393/68 396/45   
   SEEN-BY: 423/120 633/280 770/1 3634/0 12 15 27 50   
   PATH: 3634/12 154/10 280/464 229/426