1
Vote

2.0RC date format parsing error

description

Hi, this tool is very useful in my work, thanks for your great work!
I found a problem when I created my own format. The format works well in the editor, but when loading a sample log, a date parsing error occurred. I tested the same format in v1.5, it works well. So I guess it might be a problem of v2.0 RC.
Attached is my format and sample log file. Could you please help me check?

Thanks a lot!
Liu Kai

file attachments

comments

sergeys wrote Nov 1, 2013 at 6:26 PM

For me it complains "Failed to parse DateTime value '0.03.2012 16:44:14.297' of format 'd.MM.yyyy HH:mm:ss.fff'. The DateTime represented by the string is not supported in calendar System.Globalization.GregorianCalendar."

0 is not a valid day number. See http://msdn.microsoft.com/en-us/library/8kb3ddd4.aspx: "d" The day of the month, from 1 through 31.

Do you really have zero-based days?

LiuKai wrote Nov 5, 2013 at 6:32 AM

There is no zero-based days in the sample log, it is '30.03.2012', during parsing, it seems the first number '3' is missing, and '0.03.2012' is transferred to TO_DATETIME(), thus has above error.In version 1.5, with the same sample, wouldn't have such problem.

sergeys wrote Nov 5, 2013 at 10:32 AM

Please find updated format file attached.

Changes:1. Changed the regex: removed ^ at the beginning, changed the matching of the day number. When authoring the regex one should understand that it should work when applied to any random slice of input file. In your case LogJoint decided to apply the regex to a slice that had '3' cut off. The slice started from '0'. Your regex would detect that it is a valid start of a message whereas it was not.I admit that the rules are not well documented. I should probably add some automatic validation of the regexps.2. Added an option that enables auto-correction of the time drift. The problem is that your log lines are not sorted strictly by timestamp. LogJoint can auto-correct that.