Hi, I have logs from the ptp4l service that log entries as a kernel uptime duration instead of real time or epoch duration. For example, the entries might be something like:

ptp4l[1234.567] message is here
ptp4l[1235.678] message is here

When I use ElapsedDecimal, it doesn't properly parse the seconds bit before the decimal, and I also cannot set an offset. Essentially what I'm doing is copying the log file and taking a system time of the machine at the same time so that I have the last entry very closely aligned with the datetime that I pulled the data.

I'd like to be able to convert the elapsed duration to a real DateTime stamp. Any tips on how to do that?

Hi Andy,

Thanks for bringing this issue to our attention.

Looking at this, I think the elapsed and elapsedDecimal features are not implemented very well and will need to be revisited.  To make matters worse, our documentation is incorrect.

elapsedDecimal take a decimal value and converts it into a timstamp using today's date and the decimal value as the number of milliconds since the start of the process.  In this case, your decimal value represensts seconds - not milliseconds.  There is currently no way to represent seconds since application start.

To address the issue, I think elapsedDecimal should be deprecated and replaced with elapsedTimeMilliseconds and elapsedTimeSeconds.  I will get this fixed as a priority.  We should have a BETA release out early next week at the latest.

Thanks again,

Toby

Thank you for the quick update, I've just loaded in my log file and it works a treat!

Next question/request - with the time offset, is there an easier way to calculate the start time? If I can make a suggestion, allow the user to select a line and then offset based on that line. The Full Date Offset almost gets me there, but it would be much easier if I could select the last line (which I'm also pulling the current system time) and adjust the timing from there.

Glad that helped Andy.  I was just about to notify you of the new BETA release, but it sounds like you already found it.    We have also updated our documentation based on your feedback.

I am not sure if it makes sense to populate the Full Date Offset with the selected log entry timestamp.  On the one hand, I think - does it matter?  On the other, if I am offsetting the time for the whole log file, to me it makes sense to start with the first log entry.  Can you help me understand why you want to offset from the last log entry?

Primarily, I don't have the start date for the log file, only the end date! Here's an example:

Log line 1:
ptp4l[160.209]: selected /dev/ptp0 as PTP clock

Log line 3761587:
ptp4l[3779291.106]: rms 14 max 32 freq -2649 +/- 18 delay 465 +/- 1

When I pull that log (this instance is ~256MB), I have a script to get the current time and store it in a date.txt file:
Mon Jun 24 13:17:18 UTC 2024

So I know the last line is approximately the timestamp in date.txt and I want to convert all other timestamps working backward from that time.

Furthering on from the above, the time offset doesn't appear to work correctly with the new elapsedSeconds. If I do a full date offset and set the externally calculated start date and time, the date element seems to choose a date close to what I've set, but usually a few days off. For example, I set 11 May 2024 19:26:27.207 as below



But the resultant start time in the log is 10 May 2024 7:26:27.208 pm


If I then try to offset the time 23:59:59.999, the starting date then resets to today +/- 23:59:59.999.

Sorry for the repeat posts - bad etiquette, I know!

Found another issue where rolling over into 2441001 elapsed seconds rolls back to Epoch after doing the time offset:


After about 80 years in log time (26 years into the future ), this then resumes as expected once crossing into 2470000 seconds:

Hi Andy,

Thanks for the update.  We have now released LogViewPlus v3.1.15 as a BETA release to address these issues.

We considered adding the focused log entry timestamp as the base date for the time offset dialog.  The problem with this is that the focused log entry is likely to change as the dialog is closed and reopened.  The offset would remain the same, but the changing dates can be confusing for new users.  For this reason, we decided to continue to use the first log entry timestamp as the focus time.

I was not able to recreate the issue you experienced with the time offset dialog.  However, I think the problem may have been caused by closing and reopening the dialog several times.  I noticed that as a time offset is applied multiple times, things get weird as the origianl timestamp is lost.  I have tried to address this in the latest release by removing the possibility of setting a 'full date' offset when editing an existing offset.

I was able to recreate the 2441000 elapsed time issued mentioned in your post above.  This issue is resolved in the latest release.  Thanks for bringing this to our attention!  

Hope that helps,

Toby