Displaying 20 results from an estimated 8000 matches similar to: "print.POSIXct doesn't seem to use tz argument, as per its example"
2016 Dec 16
0
print.POSIXct doesn't seem to use tz argument, as per its example
>>>>> Jennifer Lyon <jennifer.s.lyon at gmail.com>
>>>>> on Thu, 15 Dec 2016 09:33:30 -0700 writes:
> On the documentation page for DateTimeClasses, in the Examples section,
> there are the following two lines:
>
> format(.leap.seconds) # the leap seconds in your time zone
> print(.leap.seconds, tz = "PST8PDT") # and in
2007 Jan 08
1
Does strptime(...,tz="GMT") do anything?
Hi All
In trying to correlate some tide gauge data I need to deal with varying
timezones. From the documentation on strptime, it seemed that the tz
variable might have some effect on the conversion, but I'm not seeing an
effect.
> strptime("20061201 1:02 PST",format="%Y%m%d %H:%M",tz="PST")+0
[1] "2006-12-01 01:02:00 EST"
>
2005 Jan 19
1
Re: [R-SIG-Mac] Formatting of time zone for POSIXct
Don,
thanks for your report.
On Jan 19, 2005, at 12:41 PM, Don MacQueen wrote:
> I'm encountering a problem formatting POSIXct objects in R 2.0.1 on OS
> X.
>
> For reference, on a Solaris system, R 2.0.1 (2004-11-15), formatting
> is correct:
>
>> Sys.time()
> [1] "2005-01-19 09:12:33 PST"
>> format(Sys.time(),'%H:%M %Z')
> [1]
2019 Aug 02
4
Infrequent but steady NULL-pointer caused segfault in as.POSIXlt.POSIXct (R 3.4.4)
The R script I run daily for hours looks like this:
while (!finish) {
Sys.sleep(0.1)
time = as.integer(format(Sys.time(), "%H%M")) # always crash here
if (new.data.timestamp() <= time)
next
# ... do some jobs for about 2 minutes ...
gc()
}
Basically it waits for new data, which comes in every 10 minutes, and
do some jobs, then gc(), then loop again. It
2007 Mar 19
3
R4.1: seq.POSIXt, tz="AEST" (PR#9572)
Times from seq.POSIXt come out wrong in AEST timezone around Feb 29 every
leap year before 1970 (on Windows XP).
According to help(DateTimeClasses), this is handled by "our own C code".
> x <- as.POSIXct("1968-02-27") # tz="AEST"
> x.gmt <- as.POSIXct("1968-02-27", tz="GMT")
> data.frame(
GMT=seq(x.gmt, by="day",
2019 Aug 04
1
Infrequent but steady NULL-pointer caused segfault in as.POSIXlt.POSIXct (R 3.4.4)
A reply from stackoverflow suggests I might have hit this bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=14023
I can confirm that this glibc bug affects my system (latest CentOS 7).
However, as far as I know, R is not multithreaded in its core. Is it
possible that some library triggered this?
Regards,
Steve
Tomas Kalibera <tomas.kalibera at gmail.com> ?2019?8?2??? ??4:59???
>
2012 Feb 02
1
Problem with GMT+/- time zones
I'm struggling with time zone version when expressed as hours offset from GMT. Can anyone confirm that the behaviour below is incorrect? It seems that the GMT offsets are backwards:
> format(as.POSIXct("2011-05-23 17:23:00", tz="Europe/London"),tz="America/New_York",usetz=T)
[1] "2011-05-23 12:23:00 EDT"
- this works.
>
2012 Dec 13
1
duplicated.data.frame() and POSIXct with DST shift
Hi,
I encountered the behavior, that the duplicated method for data.frames gives "false positives" if there are columns of class POSIXct with a clock shift from DST to standard time.
time <- as.POSIXct("2012-10-28 02:00", tz="Europe/Vienna") + c(0, 60*60)
time
[1] "2012-10-28 02:00:00 CEST" "2012-10-28 02:00:00 CET"
df <-
2004 Jan 11
1
strange behaviour when converting from char to POSIX (PR#6427)
On Sun, 11 Jan 2004, Dirk Eddelbuettel wrote:
> On Fri, Jan 09, 2004 at 06:01:27PM +0100, christoph.schmutz@meteoschweiz.ch wrote:
> > Full_Name: Christoph Schmutz, MeteoSchweiz, Switzerland
> > Version: R1.7.1, R1.8.1
> > OS: windows2000, solaris sunOS 5.8
> > Submission from: (NULL) (141.249.133.6)
> >
> >
> >
> > I'm not sure if I
2005 Apr 30
1
segfault during build of 2.1.0 on RH9; print.POSIXct implicated (PR#7827)
In attempting to build R using
rpmbuild --rebuild R-2.1.0-0.fdr.2.fc3.src.rpm
on a fairly up-to-date RedHat 9 system (that is, with patches installed
through May 1 2004), it failed at the make check-all step.
The problem was reproducible by going into the tests directory and
make test-Segfault
The last lines of the saved file no-segfault.Rout.fail are
> > ## c.POSIXct :
> >
2011 Mar 10
1
Timezone issue with strftime/strptime and %z and %Z
Hello!
I've been trying to get this right for quite a while now and fear
there is an easy solution I just don't see. I did not have this
problem in Linux, and I searched r-help and Google but did not find a
solution, but of course I am grateful for and resources I might not
have found our not understood yet.
I try to parse a time stamp with time zone. I essentially just want to
parse the
2004 Apr 23
3
time zones in POSIXt
Hi,
I have two data sources. One records time in PST time zone, the other in
GMT. I want to compute the difference between the two, but don't see
how. Here is an example where I compute time difference between
identical times each (meant to be) relative to its time zone.
> as.POSIXlt("2000-05-10 10:15:00", "PST") - as.POSIXlt("2000-05-10
10:15:00",
2005 Apr 30
2
(PR#7826) segfault during build of 2.1.0 on RH9; print.POSIXct
1) Why did you submit this *twice*, as PR#7826 and PR#7827? Please don't
be so careless of the volunteers' time.
2) > print.POSIXct
function (x, ...)
{
print(format(x, usetz = TRUE, ...), ...)
invisible(x)
}
is definitely *not* implicated. (Use of ... in two places is correct.)
3) On FC3:
> unusual_and_faults
Error: protect(): protection stack overflow
>
2005 Apr 30
0
(PR#7826) Re: ... print.POSIXct .. infinite recursion
Thank you, Jskud.
I can reproduce your problem, though not the
seg.fault, see below
>>>>> "Jskud" == Jskud <Jskud@Jskud.com>
>>>>> on Sat, 30 Apr 2005 09:04:03 +0200 (CEST) writes:
Jskud> In attempting to build R using rpmbuild --rebuild
Jskud> R-2.1.0-0.fdr.2.fc3.src.rpm
Jskud> on a fairly up-to-date RedHat 9 system (that
2011 Jun 01
6
[Bug 8198] New: rsync does not set TZ variable after chroot(), which confuses logging timestamps
https://bugzilla.samba.org/show_bug.cgi?id=8198
Summary: rsync does not set TZ variable after chroot(), which
confuses logging timestamps
Product: rsync
Version: 3.1.0
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: core
AssignedTo: wayned at
2010 Dec 16
3
Icecast Logs Timestamp in UTC
Hello,
I'm having a major problem with the timestamps in both the Icecast access.log and error.log. The timestamp on the logfiles themselves is accurate, but the logging of the various connections to my streams is in UTC. No matter how I try to configure the hwclock or the system clock, the log timestamp is always UTC, which is 8 hours ahead of my current time zone. I've even tried
2008 Feb 04
1
strftime fails on POSIXct objects (PR#10695)
R 2.6.1 on a Thinkpad T60 running up-to-date Gentoo:
Despite the documentation, which says:
'strftime' is an alias for 'format.POSIXlt', and 'format.POSIXct'
first converts to class '"POSIXlt"' by calling 'as.POSIXlt'. Note
that only that conversion depends on the time zone.
strftime fails on POSIXct objects:
> foo <-
2004 Aug 18
1
Fwd: strptime() problem? - Resolved
Hi Gabor and everybody;
Thanks Gabor, with the alternative step you've told me the problem is
resolved. Comparing the two procedures:
Extract from the source 'character' data:
> rain$ts[2039:2046]
[1] "25/03/2000 22:00:00 UTC" "25/03/2000 23:00:00 UTC"
[3] "26/03/2000 00:00:00 UTC" "26/03/2000 01:00:00 UTC"
[5] "26/03/2000 02:00:00
2005 Aug 31
1
So-called 'bug' reports PR#8102 and PR#8103
Neither of these have reached me on R-devel (and only PR#8103 is on the
archive), and they seem to be the same error although neither mentions the
other. That's 'odd', to quote one of them.
"EDT" is not a valid POSIX timezone (but, say, EST5EDT is). R's docs are
quite clear that what happens with invalid inputs is system-specific.
(Windows seems often to run home
2018 May 16
2
Date method of as.POSIXct does not respect tz
R 3.5.0
Is it intended that the Date method of as.POSIXct does not respect the
tz parameter? I suggest changing as.POSIXct.Date to this:
function (x, tz = "", ...)
.POSIXct(unclass(x) * 86400, tz = tz)
Currently, the best workaround seems to be using the character method if
one doesn't want the default timezone (which is often an annoying DST
timezone).
This came up on