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)