On 2019 Mar 20 22:31:24, you wrote to All:

 ON> PSPS. Also with the topic of TZUTC, if my engine auto calculates UTC as
 ON> 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 -----

 ON> (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)