> I think a possible alternative would be to modify parsedate() to return an > undef value in case of failure instead of barking and bailing out. > The user could then check manually whether it succeeded or not. This would be > pretty easy to fix. Yeah... that would be great, if it could be pointed at a variable ( $date = parsedate(blahblah) ), and it would "succeed" (so to speak) every time (i.e. it won't error out), but you could then simply use ( type($date) ) to test for "datetime" or "undef", and then take action based upon the result.
> now() returns a datetime type which is internally in UTC. What you probably > see is this value converted to string, e.g. string(now()) or log_info(now()). > When nxlog converts a datetime type to a string, it uses the local time > without timezone information. Sorry... yes... I should have been clear about my subsequent usage. Thanks for that clarification! As always, thanks for the help/guidance. -----Original Message----- From: Botond Botyanszki [mailto:b...@nxlog.org] Sent: Thursday, July 18, 2013 1:08 PM To: nxlog-ce-users@lists.sourceforge.net Subject: Re: [nxlog-ce-users] Validation of potential datetime value, and other date-related questions. Hi, On Thu, 18 Jul 2013 14:09:43 +0000 Marvin Nipper <marvin.nip...@westernunion.com> wrote: > Is there any simple way to test the viability of a supposed date-time > string, before attempting to use the parsedate function to convert it? > I'm attempting to avoid the overhead of some complex regex comparison > (on every log line) simply to look for potential garbage lines. Not that I'm aware of currently. > The problem > being that if I grab what I expect to be a date, at the beginning of > the log line, and then feed it to parsedate, the parsedate operation > (sometimes) fails, and all of the other lines behind it also fail > (some of which are involved in reformatting the output). I think a possible alternative would be to modify parsedate() to return an undef value in case of failure instead of barking and bailing out. The user could then check manually whether it succeeded or not. This would be pretty easy to fix. > Part of the issue with the above is that one might suggest breaking > the code snippets into multiple Exec blocks, but the current Exec > block starts by using drop() to kill off commented header lines in the > logs, so the rest of the existing code is all in an Else leg (within > that Exec block). And obviously, secondary Exec blocks, that follow a > drop(), end up generating other errors. Anyway, I had simply that > that maybe there was an "efficient" test that I'd missed. The drop() procedure has been a pain because of this behavior. There are intentions to modify this so that the execution is aborted altogether after a drop() without the need to put anything after that into an "else" block. There could be a drop_but_continue() for the rare cases when the user really wants to do something after the drop which does not deal with the log data. > Different question. I see that datetime's are stored in UTC, but I > also see that now() returns the TZ-adjusted value. Is there a way to > ask for the current time, in UTC (e.g. to easily "substitute that > value" for log file UTC date/time stamps that are corrupted)? now() returns a datetime type which is internally in UTC. What you probably see is this value converted to string, e.g. string(now()) or log_info(now()). When nxlog converts a datetime type to a string, it uses the local time without timezone information. There is strftime() to format a string representation of a datetime in any way you like. Unfortunately this function does not work uniformly across all systems, e.g. on windows the %z and %Z modifiers can produce funny output. Since this is again microsoft's standard compliance (linux/unix users should have no problem), we have no choice but to implement our own formatter function which could produce some well-known date formats (ISO6801 in localtime and UTC with timezone, RFC3339, and such). This would be another worthy addition to a future nxlog release. There was a similar thread earlier: https://sourceforge.net/mailarchive/message.php?msg_id=29535795 Regards, Botond ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ nxlog-ce-users mailing list nxlog-ce-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nxlog-ce-users ---------------------------------------------------------------------- The information transmitted, including any content in this communication is confidential, is intended only for the use of the intended recipient and is the property of The Western Union Company or its affiliates and subsidiaries. If you are not the intended recipient, you are hereby notified that any use of the information contained in or transmitted with the communication or dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the Western Union sender immediately by replying to this message and delete the original message ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ nxlog-ce-users mailing list nxlog-ce-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nxlog-ce-users
