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...
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 ;)
