{"action":"opened","issue":{"url":"https://api.github.com/repos/sfirke/janitor/issues/217","repository_url":"https://api.github.com/repos/sfirke/janitor","labels_url":"https://api.github.com/repos/sfirke/janitor/issues/217/labels{/name}","comments_url":"https://api.github.com/repos/sfirke/janitor/issues/217/comments","events_url":"https://api.github.com/repos/sfirke/janitor/issues/217/events","html_url":"https://github.com/sfirke/janitor/issues/217","id":341598198,"node_id":"MDU6SXNzdWUzNDE1OTgxOTg=","number":217,"title":"excel_numeric_to_date with include_time = TRUE can return 60 for seconds","user":{"login":"sfirke","id":7569808,"node_id":"MDQ6VXNlcjc1Njk4MDg=","avatar_url":"https://avatars3.githubusercontent.com/u/7569808?v=4","gravatar_id":"","url":"https://api.github.com/users/sfirke","html_url":"https://github.com/sfirke","followers_url":"https://api.github.com/users/sfirke/followers","following_url":"https://api.github.com/users/sfirke/following{/other_user}","gists_url":"https://api.github.com/users/sfirke/gists{/gist_id}","starred_url":"https://api.github.com/users/sfirke/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sfirke/subscriptions","organizations_url":"https://api.github.com/users/sfirke/orgs","repos_url":"https://api.github.com/users/sfirke/repos","events_url":"https://api.github.com/users/sfirke/events{/privacy}","received_events_url":"https://api.github.com/users/sfirke/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-07-16T16:56:45Z","updated_at":"2018-07-16T16:56:45Z","closed_at":null,"author_association":"OWNER","body":"Split off from #216, won't get to this in the next patch release that CRAN is requesting.\r\n\r\nHere's what I have as I started to address that floating point imprecision can cause `x %% 60` to return 60, which shouldn't be possible.\r\n```\r\n\r\n    # Because of floating point imprecision, total_sec %% 60 can return 60 for ret$sec\r\n    # E.g., 86400 * (42001.1 %% 1) = 8639.99999987427145 when it should be 8640, then it %% 60 = 60\r\n    # Presumably ret$min could also be 60\r\n    # The following code block addresses situations where seconds or minutes are 60\r\n    # See https://github.com/sfirke/janitor/issues/216\r\n    if(ret$sec == 60){\r\n      ret$min <- ret$min + 1\r\n      ret$sec <- ret$sec - 60\r\n    }\r\n    if(ret$min >= 60){\r\n      ret$hour = ret$hour + 1\r\n      ret$min = ret$min - 60\r\n    }\r\n...\r\n```\r\nBut the cascading changes here are massive.  Say it was 23:59:60 on February 28th.  That should probably be represented as the identical 00:00:00 on March 1st (if not a leap year).  The method I have above of manually incrementing each unit is too tedious.\r\n\r\nI welcome thoughts - does anyone have a solution to convert `07:00:60` to `07:01:00` in an elegant, accurate way?  And how if at all is it a problem to currently output `07:00:60`?"}}
{"actor":{"display_login":"sfirke"}}