> 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