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?

  • 2
    $\begingroup$ All meteorological data exchange works in UTC time, forget about timezones. $\endgroup$ – kakk11 Feb 2 '16 at 19:02
  • $\begingroup$ The data I have has been processed from the original to a state where it considers local time. $\endgroup$ – traggatmot Feb 2 '16 at 19:46
  • $\begingroup$ Try to find a data source that uses UTC exclusively, such as ftp.ncdc.noaa.gov/pub/data/noaa $\endgroup$ – Barry Carter Feb 3 '16 at 0:05
  • $\begingroup$ I am using processed NCDC data, specifically the Integrated Surface Database (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. $\endgroup$ – traggatmot Feb 3 '16 at 5:59
  • $\begingroup$ This is the ISD data (it links directly to it), so I think your results should be in UTC already. Could you give us a sample link to data that you think isn't in UTC? $\endgroup$ – Barry Carter Feb 3 '16 at 16:51

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.

  • $\begingroup$ Just to clarify for anyone reading, subtracting -5 is the same as adding 5. $\endgroup$ – Barry Carter Feb 3 '16 at 16:50

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.

  • $\begingroup$ 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. $\endgroup$ – haresfur Feb 2 '16 at 23:53
  • $\begingroup$ @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. $\endgroup$ – casey Feb 3 '16 at 0:20

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!


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.