rounding to tenth of a second doesn't work

[archenemies]

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]

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

[randomgambit]

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]

summoning @hadley @vspinu @archenemies :D

[archenemies]

@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]

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]

@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

[hadley]

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]

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]

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.