<p>Many good data sources will come with a UTC offset column.  This is helpful for harmonizing time zones since you can simply reverse the UTC offset to make a unified UTC dataset.  If your data doesn't have the UTC offset, then you can link to it using a table like this: </p>

<pre><code>  TZ  UTC Time
  EST   -5
  EDT   -4
  CST   -6
  CDT   -5
  MST   -7
  MDT   -6
  PST   -8
  PDT   -7
</code></pre>

<p>So for instance, if your data is in EST, simply subtract -5 from the reported time to make it UTC.</p>

CC BY-SA 3.0
2016-02-03T04:21:41.407Z
2016-02-03T05:04:09.197Z
2016-02-03T05:04:09.197Z
f.thorpe
<p>Using your example of 10 AM EST and 9 AM CST, those are both exactly the same time and another way of specifying that time is 1500 UTC or 15Z (Z being historical for GMT, for your application the difference between UTC and GMT is negligible).</p>

<p>If you know the location of your stations then you can know their timezone.  To make inter-comparisons between stations meaningful you need to reference them all at the same time and the easiest way is to express them in UTC.  You are correct that this is just a nomenclature change but this gives all locations a common reference anywhere on earth.  All meteorological data natively uses UTC and has been since telegraph was invented and weather data was exchanged over large distances.  </p>

CC BY-SA 3.0
2016-02-02T23:53:39.620Z
I think the weather data here are always recorded in standard time, not shifted for daylight time, but you should be sure before converting to UTC.
haresfur
CC BY-SA 3.0
2016-02-03T00:20:19.020Z
@haresfur Yep, knowing whether they use daylight saving time or not is important. Another good reason to find a dataset in UTC and save a headache.
casey
CC BY-SA 3.0
2016-02-02T20:37:13.097Z
2016-02-02T20:37:13.097Z
casey
<p>I think you have the right idea. Best to talk about UTC now; GMT is a poorly-defined historical term. 
One thing to beware of when doing the conversion : daylight saving. Do not make the mistake of assuming that it happens between the same dates everywhere! </p>

CC BY-SA 3.0
2016-02-03T01:06:08.603Z
2016-02-03T01:06:08.603Z
Semidiurnal Simon
<p>Does anyone know of any simple means for merging (inverse distance weighting method) hourly weather files (precip, temp, etc.) from different time zones?</p>

<p>I am creating weather data for HUC8s, and am using the 5 closest NCDC weather stations.  But some HUC8s cross over different time zones.  Has anyone figured out the easiest method for aligning weather data?</p>

<p>My thought is to put everything into GMT - so that 10am is 10am everywhere, and track the offset in a new column in my data.  I believe this would work, but am having trouble completely wrapping my head around it:</p>

<p>Focusing on a watershed that cross from CST into EST - if it was raining at 10am EST, and also raining at 9am CST (raining at the timezone division, with weather stations on either side of the timezone division), it's raining at the same time, we are just marking the 'time' differently in each location.  However, if I transformed my date/time into GMT, with a new column tracking the offset (maybe to convert it back later), it would be the same GMT time in both locations that the rain was occurring?  In effect, it is just shifting all the weather into the same time zone, and then merging based on IDW.</p>

<p>Does anyone have any simple solutions I am overlooking?</p>

CC BY-SA 3.0
2016-02-02T19:02:00.340Z
All meteorological data exchange works in UTC time, forget about timezones.
kakk11
CC BY-SA 3.0
2016-02-02T19:46:13.650Z
The data I have has been processed from the original to a state where it considers local time.
traggatmot
CC BY-SA 3.0
2016-02-03T05:59:06.003Z
I am using processed NCDC data, specifically the Integrated Surface Database (https://www.ncdc.noaa.gov/isd). The processing step cannot be changed, due to limitations in my skill set (it is coded in C#, something I do not now). It leaves me with exact hourly data for the specific values I need. I worked out how to do this in R. If people are interested, I can share the code. It basically amounts to what @farrenthorpe proposed.
traggatmot
CC BY-SA 3.0
2016-02-03T16:58:10.377Z
@BarryCarter as you can see in my comment above above, I am using processed NCDC data, which has removed the native UTC timestamp and replaced it with a local timezone timestamp that also takes care of DST.  There is no NCDC data set that I think is not in UTC; the data that I have, which is the output of a processing step which interpolates the data to exactly 1 hour intervals and generates the exact second order inputs I need (potential evaporation and so on) is in local time. Once again, do not worry about it I was able to merge using the idea in the selected answer.
traggatmot
CC BY-SA 3.0
2016-02-03T17:02:10.757Z
Ahh, I see. Yes, the data processing is something that we do internally, in my research group. I can certainly share the data with you if you'd like, but the data itself doesn't even indicate the fact that it's in a local time zone and has considered daylight savings time.
traggatmot
<meteorology><data-analysis>
How can I merge weather data from different time zones?
traggatmot
# How can I merge weather data from different time zones?

(Asked by: username_0 on 2016-02-02)

Does anyone know of any simple means for merging (inverse distance weighting method) hourly weather files (precip, temp, etc.) from different time zones?

I am creating weather data for HUC8s, and am using the 5 closest NCDC weather stations. But some HUC8s cross over different time zones. Has anyone figured out the easiest method for aligning weather data?

My thought is to put everything into GMT - so that 10am is 10am everywhere, and track the offset in a new column in my data. I believe this would work, but am having trouble completely wrapping my head around it:

Focusing on a watershed that cross from CST into EST - if it was raining at 10am EST, and also raining at 9am CST (raining at the timezone division, with weather stations on either side of the timezone division), it's raining at the same time, we are just marking the 'time' differently in each location. However, if I transformed my date/time into GMT, with a new column tracking the offset (maybe to convert it back later), it would be the same GMT time in both locations that the rain was occurring? In effect, it is just shifting all the weather into the same time zone, and then merging based on IDW.

Does anyone have any simple solutions I am overlooking?

**Tags:** meteorology, data-analysis

> **Comments:**
> **username_1**: All meteorological data exchange works in UTC time, forget about timezones.  
> **username_0**: The data I have has been processed from the original to a state where it considers local time.  
> **username_0**: I am using processed NCDC data, specifically the Integrated Surface Database (https://www.ncdc.noaa.gov/isd). The processing step cannot be changed, due to limitations in my skill set (it is coded in C#, something I do not now). It leaves me with exact hourly data for the specific values I need. I worked out how to do this in R. If people are interested, I can share the code. It basically amounts to what @farrenthorpe proposed.  
> **username_0**: @BarryCarter as you can see in my comment above above, I am using processed NCDC data, which has removed the native UTC timestamp and replaced it with a local timezone timestamp that also takes care of DST.  There is no NCDC data set that I think is not in UTC; the data that I have, which is the output of a processing step which interpolates the data to exactly 1 hour intervals and generates the exact second order inputs I need (potential evaporation and so on) is in local time. Once again, do not worry about it I was able to merge using the idea in the selected answer.  
> **username_0**: Ahh, I see. Yes, the data processing is something that we do internally, in my research group. I can certainly share the data with you if you'd like, but the data itself doesn't even indicate the fact that it's in a local time zone and has considered daylight savings time.  

---

## 3 answers

### Answer by username_2 on 2016-02-03. Score: 1 | Accepted answer

Many good data sources will come with a UTC offset column. This is helpful for harmonizing time zones since you can simply reverse the UTC offset to make a unified UTC dataset. If your data doesn't have the UTC offset, then you can link to it using a table like this:

```
  TZ  UTC Time
  EST   -5
  EDT   -4
  CST   -6
  CDT   -5
  MST   -7
  MDT   -6
  PST   -8
  PDT   -7

```

So for instance, if your data is in EST, simply subtract -5 from the reported time to make it UTC.


---

### Answer by username_3 on 2016-02-02. Score: 2

Using your example of 10 AM EST and 9 AM CST, those are both exactly the same time and another way of specifying that time is 1500 UTC or 15Z (Z being historical for GMT, for your application the difference between UTC and GMT is negligible).

If you know the location of your stations then you can know their timezone. To make inter-comparisons between stations meaningful you need to reference them all at the same time and the easiest way is to express them in UTC. You are correct that this is just a nomenclature change but this gives all locations a common reference anywhere on earth. All meteorological data natively uses UTC and has been since telegraph was invented and weather data was exchanged over large distances.

> **Comments:**
> **username_4**: I think the weather data here are always recorded in standard time, not shifted for daylight time, but you should be sure before converting to UTC.  
> **username_3**: @username_4 Yep, knowing whether they use daylight saving time or not is important. Another good reason to find a dataset in UTC and save a headache.  

---

### Answer by username_5 on 2016-02-03. Score: 1

I think you have the right idea. Best to talk about UTC now; GMT is a poorly-defined historical term.
One thing to beware of when doing the conversion : daylight saving. Do not make the mistake of assuming that it happens between the same dates everywhere!


---

