similar to: Incorrect DST time changes in DateTimeClasses

I'm still having trouble getting to grips with time classes. I wish to calculate the difference in days between events. Browse[1]> insp.j$First [1] "2002-02-19 13:00:00 NZDT" Browse[1]> spray.j$Date [1] "2001-11-29 13:00:00 NZDT" Browse[1]> insp.jk - spray.j$Date Time difference of 82 days If I save insp.jk to a vector, I get a nice useful value of 82.

Hi, I have a whole bunch of data, which looks like: 15/03/2003 10:20 1 15/03/2003 10:21 0 15/03/2003 12:02 0 16/03/2003 06:10 0 16/03/2003 06:20 0.5 16/03/2003 06:30 0 16/03/2003 06:40 0 16/03/2003 06:50 0 18/03/2003 20:10 0.5 etc. (times given on a 24 hour clock) and goes on for years. I have some code:

On 06/23/2015 04:47 PM, g wrote: > > Richard, thank you for your response. > > > On 06/23/2015 02:51 PM, Richard wrote: > <<>> > >> I agree, so my questions are: >> >> - what is your TZ? > > u.s.a. 'central time zone' - currently on 'daylight savings time'. > >> - what does "[/bin/]date" show?

Richard, thank you for your response. On 06/23/2015 02:51 PM, Richard wrote: <<>> > I agree, so my questions are: > > - what is your TZ? u.s.a. 'central time zone' - currently on 'daylight savings time'. > - what does "[/bin/]date" show? [geo at boxen ~]$ date Tue Jun 23 14:54:42 CDT 2015 > - what does your hardware clock:

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.

On Wed, 17-May-2017 at 01:21PM +0200, Peter Dalgaard wrote: |> |> Anyways, you might want to |> |> a) move the discussion to R-devel |> b) include your platform (hardware, OS) and time zone info System: Host: MTA-V1-427894 Kernel: 3.19.0-32-generic x86_64 (64 bit gcc: 4.8.2) Desktop: KDE Plasma 4.14.2 (Qt 4.8.6) Distro: Linux Mint 17.3 Rosa Machine: System:

> Date: Tuesday, June 23, 2015 03:48:36 PM -0400 > From: Jonathan Billings <billings at negate.org> > > On Tue, Jun 23, 2015 at 01:56:13PM -0500, g wrote: >> each and every time i run yum or yumex, system time is advanced >> by 5 hours. >> >> this has gone on thru several updates, maybe even upgrades. >> >> centos = 6.6 current >> yum

Sorry for the extra info required, but I had digest mode turned on and wouldn't have received the mailing till tomorrow. I have since updated the data manually, but after 'yum update tzdata' was run, the zdump -v for EST5EDT and America/New_York all still showed a date of April 1, instead of March 11. After manually fixing, it is correct. This was mostly a question about why yum

This has to do with your own timezone. If I run that code on my computer, both formats are correct. If I do this after Sys.setenv(TZ = "UTC") Then: > cbind(format(dlt), format(dct)) [,1] [,2] [1,] "2016-12-06 21:45:41" "2016-12-06 20:45:41" [2,] "2016-12-06 21:45:42" "2016-12-06 20:45:42" The reason for that, is that

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 Windows 2000 but not in Linux. Timezones of the form GMT-5, GMT+3, etc. do not work properly in Windows 2000 for nearby dates in daylight savings time although they do work for nearby dates

> On 18 May 2017, at 13:47 , Joris Meys <jorismeys at gmail.com> wrote: > > Correction: Also dlt uses the default timezone, but POSIXlt is not recalculated whereas POSIXct is. Reason for that is the different way values are stored (hours, minutes, seconds as opposed to minutes from origin, as explained in my previous mail) > I would suspect that there is something more subtle

I read a few days back on the list where the tzdata rpm was to take care of the new DST rules. I run CentOS 3 servers, and did a 'yum update tzdata' , but received a 2006a update of the rpm. Is this proper? It sure didn't fix anything. Thanks Steve Campbell campbell at cnpapers.com Charleston Newspapers

Friends I have an xts that I wish to access. Browse[2]> DATA.ba[[p]]["2012-03-20 00:59:57","bid"] bid 2012-03-20 00:59:57 1.4993 So far so good. Now putting the index into a variable: Browse[2]> Time [1] "2012-03-20 00:59:57 NZDT" Browse[2]> DATA.ba[[p]][Time, "bid"] bid Where has it gone? Looking closer....

When I say: > Sys.time() [1] "2012-11-12 21:30:14 NZDT" > But that is not what my clock on the wall and my system say. Cannot show you my clock but... worik@lemy:/tmp$ date Tue Nov 13 10:32:20 NZDT 2012 Sys.time() is returning GMT $version.string [1] "R version 2.14.1 (2011-12-22)" > Sys.timezone() [1] "NZDT" > I'm a little lost! Worik

Hello, Following Dirk's post here: https://github.com/Rdatatable/data.table/issues/1619 we would like to clarify if this is the right behaviour, and if so, the rationale behind it. Here's the summary (thanks to Dirk and Joshua): Sys.setenv("TZ"="America/Chicago") dates = as.Date("2016-03-02") + (0:3)*7 # four Wednesdays # [1] "2016-03-02"

Hi, I used to upgrade/migrated samba 3.3.10 to samba 3.4.17 with LDAP backend in place, while upgrading the CentOS from 5.5 to 5.9. In place to retain the trust relationship. The users can able to login without re-authentication from existing machines. Tested 3 XPs, and 3 Win7 but it takes 5-8 mins to login compared to 1 win7 that was re-connected (disconnected from domain, restart, then rejoin

Can someone, please, explain the difference is results below (notice the isdst value) > unlist(as.POSIXlt('2005-7-1')) sec min hour mday mon year wday yday isdst 0 0 0 1 6 105 5 181 1 > unlist(as.POSIXlt(as.Date('2005-7-1'))) sec min hour mday mon year wday yday isdst 0 0 0 1 6 105 5 181 0

Hello, I had been running Samba 4.8 for a few years without any problems, and then upgraded to 4.10. Since then I?ve been having problems with some accounts connecting, while some connect fine still. I haven?t been able to figure out why. My server is a relatively simple standalone server, using the LDAP password backend. A failing user authenticates OK and ends up like this in the logs:

Here's a curly one. I have a share mounted via smbfs on my linux desktop. This share is on a NetApp filer somewhere, but I've also tried this on a an old linux server as well, and I have the same problem. Basically, since day light savings came into effect here (NZDT or +13), any file I create on the share gets a time creation timestamp that is way out (approximately 12 hours and 48

Hi, I have a dataframe column of the form v<-c("Fri Feb 05 20:00:01.43000 2010","Fri Feb 05 20:00:02.274000 2010","Fri Feb 05 20:00:02.274000 2010","Fri Feb 05 20:00:06.34000 2010") I need to convert this to datetime form. I did the following.. lapply(v,function(x){strptime(x, "%a %b %d %H:%M:%OS %Y")}) This gives me a list that looks like