Text 7166, 88 rader
Skriven 2014-01-09 23:22:20 av mark lewis (1:3634/12.0)
   Kommentar till text 7164 av Maurice Kinal (1:153/7001.0)
Ärende: all over but the crying?
================================
 On Fri, 10 Jan 2014, Maurice Kinal wrote to mark lewis:

 ml> the '+' is simply not required in the FTN spec of TZUTC for
 ml> positive offsets

 MK> Okay.  However since the infrastructure and it's protocols I am
 MK> using to communicate, Fidonet included, requires it then they get
 MK> precidence as per usage of a transmitted utc offset.  They require
 MK> the '+' character where it is applicable such as +0000 in my
 MK> particular case.

that's all fine and well, maurice... so in your ""tosser"" you simply add that
'+' character so the rest of your system is happy ;)  when you export your
messages to FTN networks, your ""tosser"" removes that '+' from the TZUTC
control line so that everyone else is happy... seems simple enough ;)

 ml> you'll next be saying that the TLE (Two Line Element) format of
 ml> satellite tracking data is also bogus since it doesn't require a
 ml> '+' for positive numbers

 MK> Yes but the utc offset is not a number despite that it looks like
 MK> one in certain forms.  For example PST isn't a number but is an
 MK> acceptable substitute for -0800, which isn't a number despite the
 MK> 0's and 8 characters.

only numerical time offsets from UTC are allowed by the FTN TZUTC
specification... this so that the hour and minute offsets can be achived (eg:
0930 = australian central standard time)... the alphabetical time offset
representations are not allowed by the FTN TZUTC specification so their use in
other environments or even as scarificial strawmen is moot in this
discussion...

 MK> In this form the '-' character tells me that it is west of prime 
 MK> meridian.

that depends on which standard you are following... too many times i've run
into the situation where time offsets and longitudes are the reverse of what
one normally expects to see...

several firewall products provide both styles of timezone offset where the
operator selects 0800 as pacific standard and -0800 as australian west standard
or china coast time **OR** the operator may elect to use the more commonly seen
-0800 as pacific standard and 0800 as australian west standard or china coast
time...

on the longitudes thing, i've been bitten several times by satellite software
that sees -73 degrees as islamabad/omsk instead of montreal/newyork... yes,
exactly backwards similar to the above mentioned timezones thing... it is
especially surprising when the star depiction is not what one sees with their
eyes due to this reversed usage... it is extremely hard to make satellite
observations, too... especially when the stars are not in the right places for
measuring the transit path of a satellite...

in code, it is simply a matter of using either an additive or a subtractive
formula and then using the proper positive or negative offset in that
formula...

eg: midnight newyork time = 0500 GMT 
    00:00 newyork_time - (-0500) = 0500 GMT  subtractive w/ -0500 as EDT
    00:00 newyork_time + (+0500) = 0500 GMT  additive w/ +0500 as EDT


 MK> It is required to exist.  Same can be said about +0000 being 
 MK> equivalent to UTC which is not a number either.  0000 is 
 MK> meaningless without the preceding '+' character.

zero is zero is zero... it is neither positive or negative... zero is one of
those special children we all have to deal with on a daily basis... +0000 or
-0000 makes no difference at all... a positive time offset representation in
the FTN TZUTC standard does not carry the '+' symbol... it isn't that big of a
deal... especially when your ""tosser"" or other code can easily handle it...

 ml> no possibility about it

 MK> You cannot prove it and thus is pure speculation on your part.

i have too many years of your postings available as proof... especially with
your taunting usage of "DOS think" ;)

 MK> You are wrong about utc offsets so unless I admit it you could 
 MK> easily be wrong about your claim about my true motives.

hahahahaha... somewhere in there is one of the reasons why i like you, maurice
;)

)\/(ark

 * Origin:  (1:3634/12)