Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC 3164 parser assumes timestamp in UTC #37

Open
RenaultAI opened this issue Jan 6, 2017 · 1 comment
Open

RFC 3164 parser assumes timestamp in UTC #37

RenaultAI opened this issue Jan 6, 2017 · 1 comment

Comments

@RenaultAI
Copy link

Hi,

What are your thoughts on changing the syslog parser to either accept a timezone parameter or defaulting timezone to Local? Right now the RFC 3164 parser's timezone is hardcoded to UTC, and that will break for syslog clients that are not in the UTC zone. RFC 3164 suggests using the local timezone of the syslog client.

If the originally formed message has a TIMESTAMP in the HEADER
part, then it SHOULD be the local time of the device within its
timezone.

Thanks!

@abligh
Copy link
Contributor

abligh commented Jan 6, 2017

... and this has been a feature of RFC3164 which has been persistently criticised, because there is no definition of what 'local time' means, particularly if it's different for the sender and receiver. It also creates ambiguity issues when going into or out of DST (as the timezone is not transmitted it's impossible to know whether the date referred to was before or after the switch, which may straddle the transmission of the packet). This is why most implementations actually use (or should use) UTC.

I wouldn't object to being able to specify a timezone parameter (defaulting to UTC) but the default behaviour is I think correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants