Rainer: > #1 is more a spec-stunt than a real solution ;) > In 4.4, RFC 3339 says > > ### > o Use another host in the same local time zone as a gateway to the > Internet. This host MUST correct unqualified local > times that are > transmitted to other hosts. > ###
Definitely a stunt. :) This requirement is constraining deployment options. > #2 is to "tweak" the format a little bit. Honestly, I don't > like this messing with a standard, and this is very far to the edge... > > All special sequences (like "-00:00") are already taken up. > 3339, however, specifies that the "Z" UTC indicator can be > either upper or lower case. I have choosen to allow only > upper case for simplicity. We > *could* say that if the device does not know its ZT and does > not know if time is properly synced, it should use "z" (lower > case) as the TZ indicator. This would still be a valid 3339 > indicator, but definitely not be in the spirit of 3339. I think it is okay, although the distinction is not as clear as I'd prefer. I like "-----" for offset because this removes ambiguity. I know it is not consistent with RFC3339, but RFC3339 format is ONLY for situations when you know the offset, which won't always be the case for syslog clients. So, I guess in some cases RFC3339 is not appropriate. > #3 is to actually add a syslog header field "I know my TZ > info or I am synced" (Y/N) in -protcol, eventually adjecent > to the timestamp field. Honestly, this, too, does not smell > really good to me. I think the "I am sync'ed" maybe be different than "I know my TZ". For example, you maybe no be sync'ed but know your time zone. This brings up another question that maybe other people raised before. I guess there are cases when you know the time is definitely NOT synced. But when do we consider it synced? What's the precision of sync'ed? Does it mean it is sync'ed with NTP or set manually yesterday? I guess for some cases "set manually yesterday" is fine, but for other cases (say when correlating messages from multiple systems based on precise time) this is not good enough because clocks drift and manually set time can't be precise. So, maybe this is a deployment-specific decision how the "authoritative-time" flag is interpreted? Anton.
