On 2019 Mar 20 22:31:24, you wrote to All:
PSPS. Also with the topic of TZUTC, if my engine auto calculates UTC as timestamp, is TZUTC: Z valid or just 0000?
only four digits with maybe leading "+" or "-"...
http://ftsc.org/docs/fts-4008.002
----- snip -----
4. Control paragraph specification
-----------------------------
Messages which conform to this specification must add the following
control paragraph:
^aTZUTC: <current offset from UTC>
Where ^a is ASCII 1, 01h.
The offset has the format <[-]hhmm>, where hhmm is the number of
hours and minutes, zero-padded to two digits each, that local time
is offset from UTC. If local time is WEST of UTC, then the offset
is NEGATIVE. See the table below for typical offsets.
Note that the hh in a time zone offset is not limited to a maximum
of 12. This is because the International Date Line does not run
exactly along the boundary between zone -1200 and +1200. The
minutes part is 00 for most time zones.
All four digits must be present. If the offset is negative, there
must be a minus ('-', ASCII 45, 2Dh) in front of the offset.
Implementations must NOT put a plus ('+', ASCII 43, 2Bh) in front of
the offset for positive numbers, but robust implementations should
be prepared to find (and ignore) a plus if it exists.
If local time changes as a result of, for example, daylight savings
time, then the offset in the TZUTC control paragraph should change
to reflect this.
----- snip -----
(And any reason I should not adjust from local to UTC?)
you can set any time as long as the TZUTC is correct to reflect the actual local time of the post... i think i said that right...
)\/(ark
Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... RTFM: Read The Fine Manual.
---
* Origin: (1:3634/12.73)