You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chukwa.apache.org by "Bill Graham (JIRA)" <ji...@apache.org> on 2010/04/30 01:05:53 UTC
[jira] Created: (CHUKWA-485) TsProcessor mis-handles some dates
TsProcessor mis-handles some dates
----------------------------------
Key: CHUKWA-485
URL: https://issues.apache.org/jira/browse/CHUKWA-485
Project: Hadoop Chukwa
Issue Type: Bug
Components: Data Processors
Reporter: Bill Graham
Assignee: Bill Graham
Attachments: CHUKWA-485.1.patch
The configurable date format functionality in TsProcessor does the following to extract the date text to parse when a date regex isn't set:
{{recordEntry.substring(0, sdf.toPattern().length());}}
The problem with this approach is that some date formats aren't the same length as their corresponding text string and {{sdf.toPattern().length()}} produces the length of the former, not the latter. As an example the {{z}} format letter produces a timezone like 'PDT'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CHUKWA-485) TsProcessor mis-handles some dates
Posted by "Bill Graham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHUKWA-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bill Graham updated CHUKWA-485:
-------------------------------
Attachment: CHUKWA-485.1.patch
> TsProcessor mis-handles some dates
> ----------------------------------
>
> Key: CHUKWA-485
> URL: https://issues.apache.org/jira/browse/CHUKWA-485
> Project: Hadoop Chukwa
> Issue Type: Bug
> Components: Data Processors
> Reporter: Bill Graham
> Assignee: Bill Graham
> Attachments: CHUKWA-485.1.patch
>
>
> The configurable date format functionality in TsProcessor does the following to extract the date text to parse when a date regex isn't set:
> {{recordEntry.substring(0, sdf.toPattern().length());}}
> The problem with this approach is that some date formats aren't the same length as their corresponding text string and {{sdf.toPattern().length()}} produces the length of the former, not the latter. As an example the {{z}} format letter produces a timezone like 'PDT'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CHUKWA-485) TsProcessor mis-handles some dates
Posted by "Bill Graham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHUKWA-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bill Graham updated CHUKWA-485:
-------------------------------
Status: Patch Available (was: Open)
> TsProcessor mis-handles some dates
> ----------------------------------
>
> Key: CHUKWA-485
> URL: https://issues.apache.org/jira/browse/CHUKWA-485
> Project: Hadoop Chukwa
> Issue Type: Bug
> Components: Data Processors
> Reporter: Bill Graham
> Assignee: Bill Graham
> Attachments: CHUKWA-485.1.patch
>
>
> The configurable date format functionality in TsProcessor does the following to extract the date text to parse when a date regex isn't set:
> {{recordEntry.substring(0, sdf.toPattern().length());}}
> The problem with this approach is that some date formats aren't the same length as their corresponding text string and {{sdf.toPattern().length()}} produces the length of the former, not the latter. As an example the {{z}} format letter produces a timezone like 'PDT'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CHUKWA-485) TsProcessor mis-handles some dates
Posted by "Ari Rabkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHUKWA-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ari Rabkin updated CHUKWA-485:
------------------------------
Status: Resolved (was: Patch Available)
Resolution: Fixed
> TsProcessor mis-handles some dates
> ----------------------------------
>
> Key: CHUKWA-485
> URL: https://issues.apache.org/jira/browse/CHUKWA-485
> Project: Hadoop Chukwa
> Issue Type: Bug
> Components: Data Processors
> Reporter: Bill Graham
> Assignee: Bill Graham
> Attachments: CHUKWA-485.1.patch
>
>
> The configurable date format functionality in TsProcessor does the following to extract the date text to parse when a date regex isn't set:
> {{recordEntry.substring(0, sdf.toPattern().length());}}
> The problem with this approach is that some date formats aren't the same length as their corresponding text string and {{sdf.toPattern().length()}} produces the length of the former, not the latter. As an example the {{z}} format letter produces a timezone like 'PDT'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CHUKWA-485) TsProcessor mis-handles some dates
Posted by "Ari Rabkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHUKWA-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862469#action_12862469 ]
Ari Rabkin commented on CHUKWA-485:
-----------------------------------
+1 to commit. Barring objections, will do so tomorrow.
> TsProcessor mis-handles some dates
> ----------------------------------
>
> Key: CHUKWA-485
> URL: https://issues.apache.org/jira/browse/CHUKWA-485
> Project: Hadoop Chukwa
> Issue Type: Bug
> Components: Data Processors
> Reporter: Bill Graham
> Assignee: Bill Graham
> Attachments: CHUKWA-485.1.patch
>
>
> The configurable date format functionality in TsProcessor does the following to extract the date text to parse when a date regex isn't set:
> {{recordEntry.substring(0, sdf.toPattern().length());}}
> The problem with this approach is that some date formats aren't the same length as their corresponding text string and {{sdf.toPattern().length()}} produces the length of the former, not the latter. As an example the {{z}} format letter produces a timezone like 'PDT'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.