By SoBeGuy - 3 Aug 2021
What would be the correct format string to parse the following date:
2021-07-30T13:28:30.942654-04:00
The wizard generates the following string:
yyyy-MM-ddT%H:mm:ss.ffffffzzzz
However, when I view the result in the log viewer, there's no time zone column, and the time is displayed like:
1:28:30 PM.942
|
By LogViewPlus Support - 3 Aug 2021
That looks correct. Where is that time displayed - in the grid? Have you checked your time display format settings?
|
By SoBeGuy - 3 Aug 2021
Well, I was expecting it to display the time zone, but after enabing the setting to convert to my local time, I don't really need the time zone. Still, I don't understand why it doesn't display a column for the time zone, since the time zone is present in the date format.
I also have another question. Here you can see this log is being written with two different time zones, and it does display the time zone. However, it's not converting it to my local time, even though I have that setting enabled.
|
By LogViewPlus Support - 3 Aug 2021
If you want to display the timestamp, try adding zzzz to the time display format settings. You will also find settings on how timezones should be handled with regard to the display time. It may be worth modifying these to see if you can get the expected result.
Regarding the final screenshot, I would suggest that either the timezone is not being parsed (zzzz) or it is being parsed into the current time zone making the conversion redundant. If you think there may be a bug here, please send a sample log file along with recreation steps.
|
By SoBeGuy - 3 Aug 2021
It seems the problem is LVP is unable to parse Linux time zones like America/New_York. This is a pretty common logging format on Linux. Do you think you could support this?
|
By LogViewPlus Support - 4 Aug 2021
Unfortunately, no. LogViewPlus time zone logic uses the work done by Microsoft which only supports the zzzz time zone formats (UTC offsets of +/-0100, etc...). LogViewPlus enhances this with the formatter ZZZ to handle three letter time zones like GMT and EST, but it is difficult to see how this could be extended to handle geographies like "America/New_York" without significant effort.
For the moment, we need to focus our attention on other areas of the application.
Thanks for the suggestion,
Toby
|
|