Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dev.icinga.com #11147] "day -X" time specifications are parsed incorrectly #3932

Closed
icinga-migration opened this issue Feb 11, 2016 · 7 comments
Labels
bug Something isn't working
Milestone

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/11147

Created by atj on 2016-02-11 15:40:15 +00:00

Assignee: gbeutner
Status: Resolved (closed on 2016-05-11 07:26:42 +00:00)
Target Version: 2.4.8
Last Update: 2016-05-11 07:26:42 +00:00 (in Redmine)

Icinga Version: 2.4.1
Backport?: Not yet backported
Include in Changelog: 1

Please refer to #11132, #11141 and #11146 for additional context.

Based on the available documentation, time specifications of the form "day -1" should be parsed as "the last day of the month". However LegacyTimePeriod::ParseTimeSpec currently parses "day -1" as the second to last day of the month. This is due to the following code (repeated a couple of times):

            /* Negative days are relative to the next month. */
            if (mday < 0) {
                end->tm_mday--;
                end->tm_mon++;
            }

The decrementing of tm_mday is causing the issue, however it should be noted that valid values for tm_mday are 1..31 and 0..11 for tm_mon. It seems that mktime in glibc normalises the invalid values but I don't think it is safe to rely on this behaviour.

My suggestion would be to add a method to return the number of days in a month, so the code looked something like:

if (mday < 0)
    end->tm_mday = DaysInMonth(end->tm_mon) - mday;

Please let me know if this is acceptable and I will write a patch.

Changesets

2016-05-11 07:23:55 +00:00 by gbeutner ed27130

Fix: "day -X" time specifications are parsed incorrectly

fixes #11147

2016-05-12 09:09:49 +00:00 by gbeutner 89c7b5a

Fix: "day -X" time specifications are parsed incorrectly

fixes #11147

Relations:

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-03-18 13:25:55 +00:00

  • Relates set to 11146

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-03-18 13:26:02 +00:00

  • Relates set to 11132

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-03-18 13:26:19 +00:00

  • Status changed from New to Assigned
  • Assigned to set to jflach

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-05-11 06:52:21 +00:00

The mktime(3) manpage seems to suggest that this is in fact supported:

The mktime() function modifies the fields of the tm structure as follows: tm_wday and tm_yday are set to values determined from the contents of the other fields;
if structure members are outside their valid interval, they will be normalized (so that, for example, 40 October is changed into 9 November); tm_isdst is set (regardless
of its initial value) to a positive value or to 0, respectively, to indicate whether DST is or is not in effect at the specified time. Calling mktime() also sets the external
variable tzname with information about the current timezone.

However, obviously "day-1" should refer to the last day - as opposed to the second-to-last day, so this is definitely still a bug.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-05-11 07:26:11 +00:00

  • Category changed from Configuration to libicinga
  • Assigned to changed from jflach to gbeutner

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-05-11 07:26:20 +00:00

  • Target Version set to 2.4.8

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-05-11 07:26:42 +00:00

  • Status changed from Assigned to Resolved
  • Done % changed from 0 to 100

Applied in changeset ed27130.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant