Janko Thyson
2012-Jul-30 16:52 UTC
[R] Possible bug in class 'POSIXlt' when including microseconds?
Dear list, I'm a bit puzzled by an ambiguity with respect to the representation of micro-/milliseconds when using 'POSIXlt' objects. It seems that the last digit of the 'sec' attribute sometimes seems to differ from the digits shown when printing the 'POSIXlt' object. You'll find a little SO post with some example code here: http://stackoverflow.com/questions/11725517/ambiguity-with-posixlt-representation-when-microseconds-are-included. In case you don't want to have a look at that, here's another short example: |opts<- options(digits.secs=6) x<- "2012-07-30 12:10:09.123123" posix<- as.POSIXlt(x, tz="Europe/Berlin")> posix[1] "2012-07-30 12:10:09.123122 Europe/Berlin"> posix$sec[1] 9.123123 | # Manually changing the 'sec' attribute |posix$sec<- 9.123122> posix[1] "2012-07-30 12:10:09.123122 Europe/Berlin" # Still '.123122' posix$sec<- 9.123124> posix[1] "2012-07-30 12:10:09.123124 Europe/Berlin" # Now it's '.123124' in both 'representations' | Thanks a lot for any clarification on this! Janko [[alternative HTML version deleted]]
jim holtman
2012-Jul-30 17:26 UTC
[R] Possible bug in class 'POSIXlt' when including microseconds?
FAQ 7.31 In floating point, you get about 15 digits of precision. If you look at the value of time for today you will see: 1343668783 If you add 5 more digits after the decimal point, you will see that there is not resolution to a microsecond level. I usually assume that I can get millisecond resolution from POSIXct values. On Mon, Jul 30, 2012 at 12:52 PM, Janko Thyson <janko.thyson.rstuff at googlemail.com> wrote:> Dear list, > > I'm a bit puzzled by an ambiguity with respect to the representation of > micro-/milliseconds when using 'POSIXlt' objects. > > It seems that the last digit of the 'sec' attribute sometimes seems to > differ from the digits shown when printing the 'POSIXlt' object. You'll > find a little SO post with some example code here: > http://stackoverflow.com/questions/11725517/ambiguity-with-posixlt-representation-when-microseconds-are-included. > > In case you don't want to have a look at that, here's another short example: > > |opts<- options(digits.secs=6) > x<- "2012-07-30 12:10:09.123123" > > posix<- as.POSIXlt(x, tz="Europe/Berlin") > >> posix > [1] "2012-07-30 12:10:09.123122 Europe/Berlin" > >> posix$sec > [1] 9.123123 > | > > # Manually changing the 'sec' attribute > > |posix$sec<- 9.123122 >> posix > [1] "2012-07-30 12:10:09.123122 Europe/Berlin" > # Still '.123122' > > posix$sec<- 9.123124 >> posix > [1] "2012-07-30 12:10:09.123124 Europe/Berlin" > # Now it's '.123124' in both 'representations' > | > > > Thanks a lot for any clarification on this! > Janko > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code.-- Jim Holtman Data Munger Guru What is the problem that you are trying to solve? Tell me what you want to do, not how you want to do it.
Maybe Matching Threads
- Floating point precision causing undesireable behaviour when printing as.POSIXlt times with microseconds?
- Delayed input posting
- Bug or feature: using "ANY" as a generic field class (was: '[R] Is there a (virtual) class that all R objects inherit from?)
- Problems building own package (Error: "package has been build before R-2.10.0")
- Problems building own package (Error: "package has been build before R-2.10.0")