Displaying 20 results from an estimated 10000 matches similar to: "timezone conversion difficulties with the new US daylight saving time switch over"
2007 Nov 01
0
daylight saving / time zone issues with as.POSIXlt/as.POSIXct (PR#10393)
tplate at acm.org wrote:
> Running under Windows XP 64 bit, as.POSIXlt()/as.POSIXct() seem
> to think that US time zones (EST5EDT, MST7MDT) switched from daylight
> savings back to standard time on Oct 28, 2007, whereas the switch
> is actually on Sun Nov 04, 2007.
>
> =20
Not Our Problem. (This sort of thing never is. We are wholly dependent=20
on the OS for this information).
2007 Nov 01
1
daylight saving / time zone issues with as.POSIXlt/as.POSIXct (PR#10392)
Running under Windows XP 64 bit, as.POSIXlt()/as.POSIXct() seem
to think that US time zones (EST5EDT, MST7MDT) switched from daylight
savings back to standard time on Oct 28, 2007, whereas the switch
is actually on Sun Nov 04, 2007.
Examples:
> Sys.timezone()
[1] "Mountain Daylight Time"
> as.POSIXct("2007-10-30 12:38:47")
[1] "2007-10-30 12:38:47 Mountain
2020 Oct 23
0
timezone tests and R-devel
So let me try to raise this issue once more, and perhaps be more clear
about what I think the issue is..
In my opinion there is now a bug in
make check
in R-development (tested today with r79361). As I see it, I specify a
reasonable TZ environment variable and this leads to make check emitting an
error.
Best,
Kasper
On Fri, Oct 2, 2020 at 11:28 AM Kasper Daniel Hansen <
kasperdanielhansen
2020 Oct 23
1
timezone tests and R-devel
Yes, you are absolutely right and I'm pretty sure this will be fixed in
one way or another.
IMO, the failing test should simply use all.equal.POSIXt's new argument
check.tzone=FALSE.
Two simple alternatives modifying all.equal.POSIXt behaviour:
- make check.tzone=FALSE the default: this is inconsistent with other
arguments of all.equal methods, always defaulting to stricter checks
-
2003 Aug 04
0
as.POSIXct Bug when used with POSIXlt arg and tz= arg (PR#3646)
Tracking down this bug was joint work with Jermoe Asselin (jerome at
hivnet.ubc.ca) and Patrick Connolly (p.connolly at hortresearch.co.nz). We
collectively were able to determine that this is a problem in both Windows 2000
and in Linux and by testing it in our three time zones that it seems to be
daylight savings time related.
Conversion of POSIXlt datetimes to POSIXct appears to have problems.
2020 Oct 02
0
timezone tests and R-devel
Thank you for the report. In R-devel, all.equal.POSIXt() by default
reports inconsistent time zones. Previously,
> x <- Sys.time()
> all.equal(x, as.POSIXlt(x, tz = "EST5EDT"))
would return TRUE. To ignore the time zone attributes in R-devel, the
argument 'check.tzone = FALSE' needs to be used.
That said, I can reproduce the 'make check' failure in R-devel on
2020 Oct 02
2
timezone tests and R-devel
Yes, the potential issue I see is that
make check
fails when I explicitly set TZ. However, I set it to be the same as what
the system reports when I login.
Details: The system (RHEL) I am working on has
$ strings /etc/localtime | tail -n 1
EST5EDT,M3.2.0,M11.1.0
$ date +%Z
EDT
$ echo $TZ
US/Eastern
On Fri, Oct 2, 2020 at 9:48 AM Sebastian Meyer <seb.meyer at fau.de> wrote:
> Thank
2002 May 12
0
{round,trunc}.POSIXt and daylight savings time (PR#1543)
I have found what looks like a small problem in trunc.POSIXt()
involving the transition to/from standard time and daylight savings
time. Assuming my assessment is correct, I have a potential solution
to offer.
If a time in daylight savings time is rounded such that the rounded
value is on the other side of the transition, the isdst element does
not get changed accordingly. I have tested only
2010 Feb 01
1
Error with cut.POSIXt and daylight savings time switchover dates
The following code:
cut(as.POSIXct("2009-11-01 04:00:00", tz="America/Los_Angeles"), "1 day")
gives the error:
Error in seq.int(0, to - from, by) : 'to' must be finite
This is related to November 1st, 2009 being the switchover date from daylight savings time to standard time in the America/Los_Angeles time zone. In particular, in cut.POSIXt, the starting
2002 May 03
1
Daylight savings time and conversion to POSIXt (arghh!)
I have asked this question before, and received some suggestions for
work-arounds that get the job done--and they are much appreciated.
But I would still like to find out if I'm missing something, and
whether there is a direct way using POSIXt functions (as.POSIXct,
as.POSIXlt, strptime, in particular).
I have environmental data collected once per minute. Here is a subset
of 3 input
2006 Oct 27
2
POSIXct time zone and daylight savings issues
Hello,
Suppose we need a function that takes a POSIXct object and need to
calculate the time difference between it and GMT time:
gmtDiff <- function(time) {
time.gmt <- as.POSIXct(format(time, tz="GMT"))
time.plt <- as.POSIXlt(time)
dlstime <- ifelse(time.plt$isdst > 0, 1, 0)
timezone <- as.numeric(difftime(time, time.gmt, units="hours"))
2020 Oct 01
3
timezone tests and R-devel
The return value of Sys.time() today with a timezone of US/Eastern is
unchanged between 4.0.3-patched and devel, but on devel the following test
fails
all.equal(x, as.POSIXlt(x))
with
x = Sys.time()
This means that devel does not complete make tests (failure on
tests/reg-tests-2.R)
It is entirely possible that it is an error on my end, I use
export TZ="US/Eastern"
but I have been
2012 Jul 02
1
Undocumented behavior around daylight savings time?
Apologies for the intrusion. I am a lurker on list.
I have been working to convert a digitized signal from a matlab file into R
for analysis and other applications. R.matlab is working fine, and it is
easy to convert the matlab date-time number (days since year 0) into R
date-time numbers (seconds since 1970-01-01).
Unfortunately, when I cast the R date-time number into POSIXct format it
seems
2012 Sep 05
2
POSIXlt and daylight savings time
I have a data frame that contains dates, but when I use as.POSIXlt() I lose
the hours on all records. I traced this down to a particuar hour which
causes the issue...
> as.POSIXlt('2004-10-31 02:00:00')
[1] "2004-10-31"
> as.POSIXlt('2004-10-31 03:00:00')
[1] "2004-10-31 03:00:00"
How do I tell as.POSIXlt() to ignore daylight savings and just convert to
2003 Jul 31
4
timezones
I have some questions and comments on timezones.
Problem 1.
# get current time in current time zone
> (now <- Sys.time())
[1] "2003-07-29 18:23:58 Eastern Daylight Time"
# convert this to GMT
> (now.gmt <- as.POSIXlt(now,tz="GMT"))
[1] "2003-07-29 22:23:58 GMT"
# take difference
> now-now.gmt
Time difference of -5 hours
Note that the difference
2006 Sep 01
3
Date conversion with as.POSIXct and as.POSIXlt (PR#9196)
Full_Name: Erich Neuwirth
Version: 2.3.1
OS: Windows XP, Linux
Submission from: (NULL) (131.130.135.167)
Converting Sys.Date() to a POSIX compliant time type in different ways
produces inconsistent results:
> Sys.date()
[1] "2006-09-01"
> as.POSIXct(Sys.Date())
[1] "2006-09-01 02:00:00 CEST"
> as.POSIXlt(Sys.Date())
[1] "2006-09-01"
>
2006 Jan 06
1
Daylight Savings Time unknown in R-2.2.1
Under R-2.2.1, a POSIXlt date created with "strptime" has an unknown
Daylight Savings Time flag:
> strptime(20051208, "%Y%m%d")$isdst
[1] -1
This is true on both Linux (details below) and Windows. It did not
occur under R-2.1.0. Any ideas? TIA!
> Sys.getenv("TZ")
TZ
""
Version:
platform = i686-pc-linux-gnu
arch = i686
os = linux-gnu
2003 Aug 13
0
Enhancement suggestion: POSIXt0
This is a proposal for a simple partial solution to the date
problems in R. It defines new classes, POSIXct0 and POSIXlt0,
which are similar to their non trailing zero counterparts
but have no timezone or daylight time. Internally they look
like GMT times but they have their own methods.
PROBLEM
Problems with POSIX dates appear when you want to
work with daily data or time data and just want
2016 Feb 04
3
Fwd: [musl] strptime() question
There is incompatibility between R strptime and musl libc. I posted
about it on their mailing list, but they need more information I can't
provide, so I'm forwarding the message here in hope R developers can
help. Thanks.
---------- Forwarded message ----------
From: Rich Felker <dalias at libc.org>
Date: Thu, Feb 4, 2016 at 2:07 PM
Subject: Re: [musl] strptime() question
To: Alba
2003 Jun 08
0
daylight saving time problems
Hello,
sorry for my mail yesterday about the POSIXct problems. I was a bit
tired and now I found out the real problem. When importing time data
over a daylight saving time shift, R shifts two times. I don't now
whether it is a bug or a (wrongly used) feature
If you execute the following code:
--------------
test<-c("31/03/2002 0:00", "31/03/2002 0:15",