Print

Print


Also you can use tz="America/New_York" which will account for the shift from EDT to EST automatically. But you need to make sure that whoever that provides you the tidal level prediction also make the shift.

 

Ben

 

From: UF R Users List <[log in to unmask]> On Behalf Of Hao Ye
Sent: Friday, December 7, 2018 3:35 PM
To: [log in to unmask]
Subject: Re: merging by date time

 

Hi Steven,

 

When you use `mdy_hm()`, you are creating a DateTime variable and telling R how to interpret the input.

 

Let's take an example:

`mdy_hm("11/8/2017 13:30")` uses the UTC time zone by default, and you create a DateTime output that corresponds to November 8, 2017, 13:30:00 UTC.

`mdy_hm("11/8/2017 13:30", tz = "EST")` will create a DateTime output that corresponds to November 8, 2017, 13:30:00 EST.

 

I wouldn't call this shifting the time, since you are telling R how to interpret the input as an appropriate date and time.

 

If your input data from the CSV file has different time zones associated with it, perhaps because of daylight savings, then you can either split the data accordingly with two different calls to `mdy_hm()`, or use `force_tz()`, which does:

```

force_tz returns the date-time that has the same clock time as input time, but in the new time zone.

```

 

Best,

--

Hao Ye

 

 

On Fri, Dec 7, 2018 at 3:15 PM Longmire,Steven <[log in to unmask]> wrote:

How does the fact that my count data is in EDT and doesn't shift to EST on November 4th play into this? If I specify it as EST, will it just put an EST "stamp" on it? Or will it actually cause it to shift time zones? Same question with the tide data, when it is put into EST, is it now shifting time zones?

Am I better off categorizing both in UTC and subtracting the appropriate number of hours until they line up?


Thanks!


From: UF R Users List <[log in to unmask]> on behalf of Klarenberg,Geraldine <[log in to unmask]>
Sent: Friday, December 7, 2018 12:01:29 PM
To: [log in to unmask]
Subject: Re: merging by date time

 

Hi Steven

 

When using mdy_hm(counts$Date.Time) everything becomes UTC time zone:

[1] "2017-11-08 13:30:00 UTC" "2017-11-08 13:30:00 UTC" "2017-11-08 13:35:00 UTC"

   [4] "2017-11-08 13:35:00 UTC" "2017-11-08 13:35:00 UTC" "2017-11-08 13:40:00 UTC"

   [7] "2017-11-08 13:40:00 UTC" "2017-11-08 13:40:00 UTC" "2017-11-08 13:45:00 UTC"

  [10] "2017-11-08 13:45:00 UTC" "2017-11-08 13:50:00 UTC" "2017-11-08 13:50:00 UTC"

  [13] "2017-11-08 13:55:00 UTC" "2017-11-08 13:55:00 UTC" "2017-11-08 14:00:00 UTC"

 

Your Cedar Key data is in the correct time zone (EST):

attr(tidepredict$Date.Time, "tzone")

[1] “EST"

 

So do:

counts$Date.Time <- mdy_hm(counts$Date.Time, tz="EST”)

 

 

Best

 

Geraldine Klarenberg, PhD

Post-Doctoral Associate

Department of Wildlife Ecology and Conservation / Agricultural and Biological Engineering

University of Florida

Tel: 352-294-7581

Cell: 386-517-3952

 

 

 



On Dec 7, 2018, at 11:16 AM, Longmire,Steven <[log in to unmask]> wrote:

 

Hi everyone,

 

I have a (large) dataset of tide level predictions that are in an interval of every five minutes, and I have a (large) dataset of bird observations with a date.time stamp. I am trying to see if there is a correlation with tide level and bird counts. 

 

Issue: whenever I try to merge the two data frames by date.time using 'left_join', it LOOKS like it works, and the date.times seem to line up, but when comparing the tide levels to the original data set's tide levels at the same time stamp, it is very off (shifted by about 5 hours or so). I think it has something to do with the date.times, because when I converted both to numeric to compare, two of the seemingly identical times gave different numerical values and tide levels.

 

Any help is appreciated!

 

Steven

 

 

This list strives to be beginner friendly. However, we still ask that you PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. <tidehelp.R><birdcamcountsfinal.csv>

 

This list strives to be beginner friendly. However, we still ask that you PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.

This list strives to be beginner friendly. However, we still ask that you PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.

This list strives to be beginner friendly. However, we still ask that you PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.

This list strives to be beginner friendly. However, we still ask that you PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.