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

rounding to tenth of a second doesn't work #502

Closed
archenemies opened this Issue Dec 21, 2016 · 9 comments

Comments

Projects
None yet
4 participants
@archenemies

archenemies commented Dec 21, 2016

I would expect floor_date(...,"0.1 seconds") to either floor my date to the nearest tenth of a second, or throw an error. It does neither:

> t=Sys.time()
> x=as.numeric(t); x-floor(x)
[1] 0.8007953
> x=as.numeric(floor_date(t,"0.1 seconds")); x-floor(x)
[1] 0

The problem seems to be in parse_period_unit:

> lubridate:::parse_period_unit("5 seconds")
$n
[1] 5

$unit
[1] "second"

> lubridate:::parse_period_unit("0.1 seconds")
$n
[1] 1

$unit
[1] "second"
@vspinu

This comment has been minimized.

Member

vspinu commented Dec 22, 2016

Yeh. Fractional seconds and other units are not supported (yet). Need to throw an error here.

@randomgambit

This comment has been minimized.

randomgambit commented Jan 13, 2017

Hello! I was about to submit a request for rounding at the milliseconds level but I see this issue is already being raised here. Any plans on implementing this soon? This feature is very important - a promising package such as lubridate just cannot afford not to have this sub-second rounding.

Thanks!

@randomgambit

This comment has been minimized.

randomgambit commented Jan 13, 2017

@archenemies

This comment has been minimized.

archenemies commented Jan 13, 2017

@randomgambit: I have to say that I find your rhetoric amusing, but I agree with you in principle; there is no reason why this library shouldn't be able to round to fractional seconds. Implementing that should be much easier than what's already implemented - rounding to hours, months, years, 15 minutes, etc.

However, I haven't had very good luck getting @hadley to respond to bugs in his libraries. He's too busy writing more libraries! I would suggest that you try working around the problem, or copy-pasting the relevant code into your package and fixing it yourself.

@randomgambit

This comment has been minimized.

randomgambit commented Jan 13, 2017

thanks for your feedback!

I see your point but this does not make sense to me. What is the purpose of having a tidyverse if nobody cares about bugs? I know this is a bit harsh (because the packages so far work great) but being more responsive to users is an absolute priority.

I am coming from Python where I mostly used Pandas. In my humble opinion Pandas is superior to dplyr EXCEPT in two points:

  • charting, where ggplot is the absolute master
  • simplicity of the syntax in dlyr

In particular, I feel the tidyverse is really poor when it comes to processing timestamps. Mostly missing are resampling methods that reproduce Pandas resample and ways to group timestamps by some user-defined time periods (say, 200 milliseconds). That is why I jumped on this thread: flooring a timestamp at the millisecond level is super basic stuff in my opinion...

In any case, dont misundertand me. R is great, the tidyverse is great. It probably needs some more focus from hardcore users to reach full maturity.

@archenemies

This comment has been minimized.

archenemies commented Jan 14, 2017

@randomgambit: I appreciated learning about the Python world.

I'm attaching my workaround, in case anyone is interested.

floor_date_frac.R.txt

Here's a diff so you can see what I changed:

floor_date_frac.diff.txt

The diff is against this file, which just has copies of the original "lubridate" functions:

floor_date_frac_orig.R.txt

@tidyverse tidyverse locked and limited conversation to collaborators Jan 14, 2017

@hadley

This comment has been minimized.

Member

hadley commented Jan 14, 2017

This conversation doesn't seem to be going anywhere useful so I've locked it for now. We'll look at the original issue when we next prepare for a release.

@vspinu vspinu added this to the 1.7.0 milestone Oct 4, 2017

@vspinu

This comment has been minimized.

Member

vspinu commented Oct 5, 2017

This was fixed in #519, but documented only now.

Rounding to fractions of a second is a very imprecise operation due to limited precision of POSIXct objects (double). Even rounding to .1s will likely get you into trouble. Consider:

> as.POSIXct("2009-08-03 12:01:59.3")
[1] "2009-08-03 12:01:59.2 CEST"
> 
> (x <- ymd_hms("2009-08-03 12:01:59.23"))
[1] "2009-08-03 12:01:59.23 UTC"
> ceiling_date(x, ".1 sec")
[1] "2009-08-03 12:01:59.2 UTC"

@vspinu vspinu closed this Oct 5, 2017

@vspinu

This comment has been minimized.

Member

vspinu commented Oct 7, 2017

Even rounding to .1s will likely get you into trouble.

It's actually a bug in POSIXt printing methods.:

> (x <- as.POSIXct("2009-08-03 12:01:59.3"))
[1] "2009-08-03 12:01:59.2 CEST"
> as.numeric(x)
[1] 1249293719.3

Double precision is actually pretty good in that range.

shrektan pushed a commit to shrektan/lubridate that referenced this issue Apr 10, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.