REPLY: 2:280/464.113 5c853a5a   
   MSGID: 1:3634/12.73 5c854daa   
   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 10 16:24:58, you wrote to me:   
      
    ml>> don't know where you got that from but it is not totally correct   
      
    MK> From you in a prior messages, the latest being to Ozz stating, and I   
   qoute;   
      
    ml>> while this is true, fidonet uses the TZUTC control line to store   
    ml>> the UTC offset so there is no confusion like you describe...   
    ml>> numbers without a sign are positive and the only sign used is   
    ml>> the '-' which easily indicates a negative...   
      
    MK> The above is very similar to prior statements you have made about the   
   TZUTC   
    MK> control line.   
      
   and the problem is???   
      
    ml>> it will be a number at some point to be able to do the math needed...   
      
    MK> An example usage would great.  Something like this that I would use for   
   the   
    MK> message I am replying to;   
      
    MK>   date --date="10 Mar 19  10:25:00 -0400" = Sun Mar 10 14:25:00 UTC 2019   
      
    MK> However in that case it doesn't show the conversion to a number(s), which   
   I   
    MK> would assume to be unixseconds, which is indeed a number representing   
    MK> seconds.   
      
   exactly... the numeric string representation must be converted to a number for   
   the math... the tools you are using are doing that behind the scenes :shrug:   
      
    MK>   date --date="10 Mar 19  10:25:00 -0400" +%s = 1552227900   
    MK>   date --date="@1552227900" = Sun Mar 10 14:25:00 UTC 2019   
      
    MK> I could compilcate the above by writing a program to use strftime() but I   
    MK> doubt it would be better than the above examples using coreutils' date.   
      
   one ""problem"" here is that you are using RFC-oriented tools... they do not   
   work like FTN tools do so you are forced to either 1) convert their output as   
   needed or 2) complain about one side or the other not being ""done   
   properly""...   
      
    MK> Every available source I have seen never bothers to correct for utc   
    MK> offsets, nevermind displaying the offset so that a reader can determine   
    MK> that the displayed message originated in a different timezone.   
      
   your horizon is rather limited, though... anyone reading your posts for any   
   real length of time can see that...   
      
    MK> If you know different I'd appreciate hearing about it but from   
    MK> everything I have seen thus far the TZUTC does absoultely nothing and   
      
   i've used TZUTC specifically to display times in the local-to-the-bbs   
   timezone... there have been comments about how can a message be written in the   
   future but when it is pointed out that the message originated in Oz and is 12   
   or so hours ahead of new york, then it makes sense... not all systems do this   
   and there may very well be no indication that timezone conversion is even   
   being done... if the software you use and have seen hasn't made use of TZUTC,   
   that's an implementation problem... or not if they don't care to use it and   
   simply display the time stamps as given...   
      
    MK> is wrong given the lack of the + character where applicable.   
      
   again, you are stuck in non-FTN mode...   
      
   )\/(ark   
      
   Always Mount a Scratch Monkey   
   Do you manage your own servers? If you are not running an IDS/IPS yer doin' it   
   wrong...   
   ... Some people pay a compliment as if they expected a receipt.   
   ---   
    * Origin:  (1:3634/12.73)   
   SEEN-BY: 15/0 2 18/200 19/36 34/999 90/1 104/57 116/18 123/140 1970   
   SEEN-BY: 153/7715 218/700 220/60 222/2 226/17 229/107 426 452 1014   
   SEEN-BY: 230/150 152 240/1120 5832 249/206 317 400 250/1 261/38 100   
   SEEN-BY: 261/1466 266/512 267/155 275/100 280/464 282/1031 1056 291/1   
   SEEN-BY: 291/111 317/3 320/119 219 322/757 340/400 342/13 200 393/68   
   SEEN-BY: 396/45 633/0 267 280 281 408 412 640/1384 712/132 620 848   
   SEEN-BY: 712/886 770/1 801/161 189 2320/105 3634/12 5020/715 1042   
   PATH: 3634/12 261/38 712/848 633/280 229/426