Yes, you are right that information about local time zone of the originator is lost. We chose DateTime because it is a more common type and easier to use.
Details about TIMESTAMP parsing process:
- The
1985-04-12T19:20:50.52-04:00 is parsed as DateTime(date, 19:20:50.52) and the -04:00 time zone.
- The
DateTime is transformed to UTC = DateTime(date, 23:20:50.52)
- The
DateTime is transformed to machine's local time and stored in SyslogMessage.Timestamp.
So, if the server application simply "prints" the SyslogMessage.Timestamp of all receiving messages, they are all shown in the same (machine local) time zone and it is easily comparable to the clock on that machine as well as the SyslogMessageReceivedEventArgs.ReceivedTime value (which is also in machine local time).
If you need to know the original time zone, please leave a comment here with description of your use case. We will think about a way to provide this information (e.g. SyslogMessage.GetTimestampOffset() or something like that). However, please note that clients are not required to use the local time zone format. They can use UTC. Also please note that in previous version of the Syslog protocol (RFC 3164) the TIMESTAMP does not use time zones at all. So, you can end up in messages with an offset and messages without it.
The possible workaround to get the information is to parse the whole message for yourself. It can be done by using the SyslogMessageFormat.Plain like this:
var binding = new SyslogBinding(...){ Format = SyslogMessageFormat.Plain };
server.Bind(binding);
In this case, the server does not parse the message - the whole message data are accessible using the SyslogMessage.Text property.
Note: If you choose Legacy instead Plain format, only the <PRI> part of the Syslog message is parsed, the Facility and Severity properties are filled, the <PRI> value will not be part of the SyslogMessage.Text property.
