> Just noticed this in RFC 3339 (Section 4.4):
>
> "Systems that are configured with a local time, are unaware
> of the corresponding UTC offset, and depend on time
> synchronization with other Internet systems, MUST use a
> mechanism that ensures correct synchronization with UTC."
>
> Since -protocol is a distributed protocol where multiple
> hosts can generate syslog messages to one syslog server, one
> can say that syslog "depends on hosts synchronization with
> other Internet systems".  Does this mean that syslog clients
> and servers MUST be aware of their UTC offset?  Are we going
> to require this in -protocol?  Besides, I don't think RFC
> 3339 specifies any designation for "unknown" offset, so what
> will such client provide?

Actually, I think we can't ensure this. The real world is against us.
You are right, I should specify that a syslog sender MUST offer a way
learn its time zone, but I am very hesitant to demand time sync for
syslog. I guess everybody in this WG knows how important time sync is,
yet this is a real-life issue. Admin's don't use NTP, they don't
configure time zones and device clocks are often set to wild values.

So I think we should demand the capability to set the time zone in any
syslog sender - but not go any further.

>
> Anton.
>
> PS:  BTW, just as an FYI, I searched rfc-editor.org web site
> and came across only one other RFC which uses RFC 3339 format
> (RFC3340).  I think if we are worried about acceptability of
> -protocol, this could be yet another slight concern.  I think
> RFC 3339 time stamp is unlike anything that is in wide use
> and people may have some initial reservations about it until
> it becomes more accepted.  I like it, accept for "T" and "Z"
> characters.

I, too, disliked this when I came across it the first time. But when you
begin to actually develop applications, the "T" is a great, quick
shortcut to detect that it is actually an ISO date.

> Unfortunately, ANSI and ISO standards are worse.

I think this is the most important argument why I selected 3339 - I
don't like to invent yet another timestamp, the older timestamps either
lack the year or the time zone or resolution or ... and the other
standards are worse. Plus, I like to stick refering to RFCs, because
these are available without purchasing (expensive) books [which also
means RFCs are instantly available when you need them...].

Rainer


Reply via email to