{"action":"created","issue":{"url":"https://api.github.com/repos/rstats-db/DBI/issues/42","labels_url":"https://api.github.com/repos/rstats-db/DBI/issues/42/labels{/name}","comments_url":"https://api.github.com/repos/rstats-db/DBI/issues/42/comments","events_url":"https://api.github.com/repos/rstats-db/DBI/issues/42/events","html_url":"https://github.com/rstats-db/DBI/issues/42","id":110842364,"number":42,"title":"Think about return types for date, time and timestamp","user":{"login":"krlmlr","id":1741643,"avatar_url":"https://avatars.githubusercontent.com/u/1741643?v=3","gravatar_id":"","url":"https://api.github.com/users/krlmlr","html_url":"https://github.com/krlmlr","followers_url":"https://api.github.com/users/krlmlr/followers","following_url":"https://api.github.com/users/krlmlr/following{/other_user}","gists_url":"https://api.github.com/users/krlmlr/gists{/gist_id}","starred_url":"https://api.github.com/users/krlmlr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/krlmlr/subscriptions","organizations_url":"https://api.github.com/users/krlmlr/orgs","repos_url":"https://api.github.com/users/krlmlr/repos","events_url":"https://api.github.com/users/krlmlr/events{/privacy}","received_events_url":"https://api.github.com/users/krlmlr/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2015-10-11T08:06:28Z","updated_at":"2015-11-10T08:48:35Z","closed_at":null,"body":"Current situation:\r\n\r\n- Dates are returned as \"Date\" class\r\n- Times are returned character, or integer (number of seconds, MySQL only)\r\n- Timestamps are returned character, or POSIXct (MySQL only)\r\n\r\nIt is unclear if, and how much, the DBI driver should abstract the DB server's understanding of these types. The current MySQL convention looks good for dates and timestamps, and should be adopted by the other backends. The \"time\" type is tricky: It doesn't seem to have a time zone, and probably represents a duration in most cases, but this cannot be relied on. Still, a `lubridate::duration()` might be a good bet here.\r\n\r\nFor now, the test tests for the \"character\" data type.\r\n"},"comment":{"url":"https://api.github.com/repos/rstats-db/DBI/issues/comments/155360054","html_url":"https://github.com/rstats-db/DBI/issues/42#issuecomment-155360054","issue_url":"https://api.github.com/repos/rstats-db/DBI/issues/42","id":155360054,"user":{"login":"krlmlr","id":1741643,"avatar_url":"https://avatars.githubusercontent.com/u/1741643?v=3","gravatar_id":"","url":"https://api.github.com/users/krlmlr","html_url":"https://github.com/krlmlr","followers_url":"https://api.github.com/users/krlmlr/followers","following_url":"https://api.github.com/users/krlmlr/following{/other_user}","gists_url":"https://api.github.com/users/krlmlr/gists{/gist_id}","starred_url":"https://api.github.com/users/krlmlr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/krlmlr/subscriptions","organizations_url":"https://api.github.com/users/krlmlr/orgs","repos_url":"https://api.github.com/users/krlmlr/repos","events_url":"https://api.github.com/users/krlmlr/events{/privacy}","received_events_url":"https://api.github.com/users/krlmlr/received_events","type":"User","site_admin":false},"created_at":"2015-11-10T08:48:35Z","updated_at":"2015-11-10T08:48:35Z","body":"@hannesmuehleisen: Unfortunately, numbers can't always stay numbers in R without sacrificing precision. For timestamps stored as milliseconds since the epoch, using `numeric` might just work (at lest for the next few millennia) -- but not necessarily for generic 64-bit values.\r\n\r\nIf there's a new \"data types\" package, I agree that it shouldn't include mandatory dependencies itself. But I still don't see why DBI shouldn't import this \"data types\" package. Conversion to and from R's internal data types (with mutable warnings if precision is lost) always will be possible."}}