<p>I am grateful to Daryl Herzmann at Iowa State, who wrangles data at the <a href="https://mesonet.agron.iastate.edu/" rel="nofollow noreferrer">Iowa State Environmental Mesonet</a> for providing an off-exchange answer.</p>

<ul>
<li><p>Synoptic reset times are between 51 and 57 minutes past the hour, depending on the site. A possible way to automate the use of ASOS data is to find the modal minute value in the data. This seems highly likely to be the reset minute.</p></li>
<li><p>The most quoted daily rainfall total is measured midnight to midnight,  local standard time, by summing the synoptic hourly total. Because it is standard time, DST is ignored.</p></li>
<li><p>I have created <a href="https://github.com/rmcd1024/daily_precipitation_totals/" rel="nofollow noreferrer">a github site</a> that includes R code to compute daily precipitation totals from ASOS data. This code:</p>

<ul>
<li>Uses the modal minute as the ASOS reset minute</li>
<li>Converts the time from GMT to local</li>
<li>Subtracts 3600 seconds if DST is in effect</li>
</ul></li>
</ul>

<p>Daryl has a <a href="https://mesonet.agron.iastate.edu/present/130903_isu/isumet_fall2013_web.pdf" rel="nofollow noreferrer">presentation that discusses precipitation measurement</a>. Thank you Daryl!</p>

CC BY-SA 3.0
2017-06-20T04:01:20.787Z
I'm still not sure why you want to account for DST. What's the advantage or reason for that?
haresfur
CC BY-SA 3.0
2017-06-20T04:09:53.647Z
Think about what happens when you switch from standard to DST. In New York you go from GMT - 0500 to GMT -0400. At 2am it becomes 3am. In the Fall you go from 2am to 1am. What do you with precipitation between 2am and 3am in the spring, or between 1am and 2am in the Fall? You've got 23 and 25 hour days. I'm not saying you can't handle this in some way, but it seems much cleaner to just ignore DST.
Robert McDonald
CC BY-SA 4.0
2021-12-05T06:01:18.850Z
Suggest you accept this answer, as it's a great resource.  I've followed Daryl for a long time, he has some superb information.
JeopardyTempest
CC BY-SA 4.0
2021-12-06T23:31:09.593Z
@JeopardyTempest I'm not sure what you're suggesting. I did accept my answer which cites Daryl.
Robert McDonald
CC BY-SA 4.0
2021-12-07T02:18:01.747Z
Sorry for the trouble, must've misseen it.  Thanks for taking the time to make the answer (and respond to my aloof comment!)
JeopardyTempest
CC BY-SA 3.0
2017-06-20T03:47:22.763Z
2017-06-20T03:47:22.763Z
Robert McDonald
<p>Typical synoptic (hourly) obs come in about 51 past the hour (sometimes a couple minutes off).  The other reports you're seeing are generally subops (SPECIs) which generally only report precip since the last ob given, but the total of which should always be reflected in the hourly.</p>

<p>So for 2136/2148/2149 timed obshour... you just use the 0.24 from 2149, and it should include the others in it (so skip the others that would lead to double-counting).</p>

<p>On the other hand, the 659 ob being smaller than the 651 ob makes sense... as 659 is in the NEW hour... so would be reflected in the 751 ob (which is indeed higher).</p>

<p>I didn't get a chance to look too closely, but looks like all of these are unfortunately altered forms of the data.  I believe typical full data should have METAR or SPECI in it to indicate which obs you want?</p>

<p>But no big deal, if you look back at <a href="https://mesonet.agron.iastate.edu/cgi-bin/request/asos.py?station=LGA&amp;data=all&amp;year1=2013&amp;month1=6&amp;day1=6&amp;year2=2013&amp;month2=6&amp;day2=8&amp;tz=Etc%2FUTC&amp;format=comma&amp;latlon=no&amp;direct=no&amp;report_type=1&amp;report_type=2" rel="nofollow noreferrer">the rawer-looking data you gave</a>, looks like you can find which ones you want by looking for the ones with SLP reported right about the end.  Or, even better, just look for the 6**** fields right about the end, which are the 6 hour total precipitation.  Just add the four of those up, and you'll have the daily total.</p>

<p>If you're trying to accomplish all this in Excel, some formulas could be worked up to automatically take what you need from the day's data, or you could use a regex in <a href="https://regex101.com/" rel="nofollow noreferrer">any</a> of the variety of online regex testers.  Or writing some sort of script could save a lot of time if you're downloading a lot of data.  But the rawer data is often safer and more easy to work with.</p>

<p>I think I used a page like <a href="http://www.met.tamu.edu/class/metar/quick-metar.html" rel="nofollow noreferrer">this</a> for more info back in the day when I had to do it.</p>

CC BY-SA 3.0
2017-06-17T03:14:25.667Z
Thank you! The confirmation of 51 minutes past the  hour is helpful but I still can't find a source.  The other wrinkle is that  the daily precipitation totals seem to ignore daylight savings time. With this change, which I also can't find documented anywhere, the totals most days exactly match the official totals.
Robert McDonald
CC BY-SA 3.0
2017-06-17T14:35:25.870Z
I should have mentioned that you are correct that the data I presented was "altered". I did this to clarify the question. The actual ASOS data from Iowa State has the raw METAR strings and numerous additional fields, some of which, such as precipitation, are obviously derived from the METAR.
Robert McDonald
CC BY-SA 3.0
2017-06-17T16:21:08.177Z
No worries, I thought one of the other sites you'd used presented it that way.  Not a problem, helpful :-)  I tried to find a source for the 51ish info too.  Some suggested it's more like 55.  Think it may have even varied over time or by countries/regions.  But 51 or 52 is the number I'm generally used to over the past 15 years of viewing metar :-)  Indeed looks like you are right that the 6 hourlies won't be useful, because they're 0/6/12/18Z, whereas indeed midnight to midnight won't match that.
JeopardyTempest
CC BY-SA 3.0
2017-06-17T16:21:58.063Z
I believe it's midnight to midnight regardless of DST or not (which is slightly intriguing, because it means the period has subtly shifted for a few weeks in fall/spring based upon DST changes through the years, though honestly the impact on highs/lows/etc is probably trivial)
JeopardyTempest
CC BY-SA 3.0
2017-06-17T16:50:17.157Z
I tried midnight to midnight local time but I can't match daily precipitation totals unless I undo DST and keep the LGA time offset at -0500. Using midnight to midnight allowing DST, the daily totals I compute are off. Documentation would be preferable to this kind of reverse-engineering!
Robert McDonald
CC BY-SA 3.0
2017-06-19T14:40:18.943Z
I think my question is resolved, see the top of my original post. You might be interested in the linked presentation there. I was thinking more about DST in daily rainfall calculations and concluded that precipitation totals probably had to ignore it, because otherwise one hour would be missed and another double-counted every year. Or there would be some other funky workaround. Again, thanks for your responses!
Robert McDonald
CC BY-SA 3.0
2017-06-19T15:28:17.110Z
@rmcd no problem, glad you got it worked out.  I would suggest you revert the question to your earlier version, as others coming here may not be able to recognize the problem you had as easily.  And then post your fixes as an answer and accept it so others can see what worked.  That way it remains question and answer :-)
JeopardyTempest
CC BY-SA 3.0
2017-06-19T21:49:21.370Z
Interesting. In Australia the standard day for weather measurements ends at 9:00 AM. I believe this is primarily done because it is hard to get people to make manual measurements at midnight. It does complicate database queries. I agree with the suggestion to write a script or function. Daylight time is ignored because otherwise the length of the day would change.
haresfur
CC BY-SA 3.0
2017-06-19T22:03:03.413Z
Just another comment: If it makes a difference to your analysis whether rain fell 10 minutes before midnight or 10 minutes after, you'd better start propagating your uncertainties!
haresfur
CC BY-SA 3.0
2017-06-19T22:45:37.933Z
@haresfur, that's a strange one.  That would mean your morning low is actually recording as yesterday???  Plus sunrise isn't until almost 8 this time of year in places like Heywood and Hobart, it seems one cold night would set two separate low temps.  Maybe related to Australia being between UTC+8 and UTC+10 (though not UTC+9 ironically)???  In the US we do choose alternate times, like 12z-12z for tornadoes, but all in a quest to best delineate separation so one day's events don't improperly reflect as the next day's.  9:00 AM to 9:00 AM for temps wouldn't seem to do that.
JeopardyTempest
CC BY-SA 3.0
2017-06-20T03:48:45.080Z
@JeopardyTempest: I've converted the question and posted an answer. Thanks for the suggestion. I've also posted R code to a github site.
Robert McDonald
CC BY-SA 3.0
2017-06-20T03:58:39.403Z
By moving the end of the day later on the clock, I think you are less likely to have a cold night split between two days. Just think of it as the day starting when you get up in the morning and ending when you get up the next day. Dawning of a new day and all that. Seems to me shortly after sunrise makes a lot of sense.
haresfur
CC BY-SA 3.0
2017-06-20T17:34:54.010Z
@rmcd: Awesome!  Very passionate about working to improve all our learning, so much thanks :-)
JeopardyTempest
CC BY-SA 3.0
2017-06-16T20:27:23.947Z
2017-06-17T12:31:40.520Z
2017-06-17T12:31:40.520Z
JeopardyTempest
<p>I would like to use <a href="https://mesonet.agron.iastate.edu/request/download.phtml" rel="nofollow noreferrer">ASOS data from Iowa State University</a>   to compute daily rainfall totals for specific locations. Using ASOS, I am unable to match the official NWS totals. I am assuming that the definition of a day is midnight to midnight, local time.</p>

<p>For example: <a href="https://www.weather.gov/media/okx/Climate/Almanacs/LGA/lgajun.pdf" rel="nofollow noreferrer">KLGA had a record rainfall total of 3.33"</a>  on June 7, 2013. An excerpt of the ASOS data covering June 7 is below. The "D" and "H" columns are EDT. It appears that rainfall totals are cumulative and reset hourly at 51 minutes (see hours 12 and 13 EDT for example). But I am unsure how to interpret certain cases. What do I do with hour 21, which reports 0.21" at 36 minutes, 0 at 48 minutes, and 0.24" at 49 minutes. Does that 0 denote a reset prior to 51 minutes, implying a total of 0.45" for that hour? Or does it indicate something else, such as a temporary cessation?</p>

<p>The general questions are: a) how does one parse the p01i column, and b) should it be possible to use ASOS precipitation data to match official NWS totals? Thanks!</p>



<p><a href="https://mesonet.agron.iastate.edu/cgi-bin/request/asos.py?station=LGA&amp;data=all&amp;year1=2013&amp;month1=6&amp;day1=6&amp;year2=2013&amp;month2=6&amp;day2=8&amp;tz=Etc%2FUTC&amp;format=comma&amp;latlon=no&amp;direct=no&amp;report_type=1&amp;report_type=2" rel="nofollow noreferrer">Excerpt from ASOS data:</a>
<code>
GMT                     M   D    H   M  p01i
...
2013-06-07T16:23:00Z    6   7   12  23  0.11
2013-06-07T16:43:00Z    6   7   12  43  0.19
2013-06-07T16:51:00Z    6   7   12  51  0.21
2013-06-07T17:35:00Z    6   7   13  35  0.18
2013-06-07T17:51:00Z    6   7   13  51  0.22
...
2013-06-08T01:16:00Z    6   7   21  16  0.18
2013-06-08T01:29:00Z    6   7   21  29  0.21
2013-06-08T01:36:00Z    6   7   21  36  0.21
2013-06-08T01:48:00Z    6   7   21  48  0
2013-06-08T01:49:00Z    6   7   21  49  0.24
2013-06-08T02:47:00Z    6   7   22  47  0.22
2013-06-08T02:51:00Z    6   7   22  51  0.22
2013-06-08T03:51:00Z    6   7   23  51  0.11
2013-06-08T03:58:00Z    6   7   23  58  0
</code></p>

<p><strong>Edit:</strong> See below. Note that the value of p01i at 6:59 (0.01") is less than that at 6:51 (0.05"), and greater than that at 7:40 (0"), which in turn is less than that at 7:51 (0.09"). What exactly is being reported here? </p>

<p><code>
GMT                     M   D   H    M  p01i
2013-06-07T10:51:00Z    6   7   6   51  0.05
2013-06-07T10:59:00Z    6   7   6   59  0.01
2013-06-07T11:40:00Z    6   7   7   40  0
2013-06-07T11:51:00Z    6   7   7   51  0.09
</code></p>

<p><strong>Edit #2</strong>: @JeopardyTempest  confirms the importance of 51 minutes past the hour. I have an algorithm that (almost!) works. Assume:</p>

<ul>
<li>The day is measured from midnight to midnight local time, <em>without</em> a DST adjustment. So in June, LGA remains at -0500.</li>
<li>Precipitation totals are accumulated to 51 minutes each hour</li>
</ul>

<p><a href="https://www.wunderground.com/history/airport/KLGA/2013/6/16/MonthlyHistory.html?req_city=KLGA&amp;req_state=NY&amp;req_statename=New+York&amp;reqdb.zip=11371&amp;reqdb.magic=5&amp;reqdb.wmo=99999&amp;MR=1" rel="nofollow noreferrer">The official daily 2013 rainfall totals for June 2, 3, 6, and 7</a> are 0.11, 0.96, 0.10, 3.33, 0.79. Using the algorithm above with the ASOS data for the same days yields 0.11, 0.96, 0.10, 3.32, 0.80.</p>

CC BY-SA 3.0
2017-06-16T10:30:42.413Z
They are 'hourly accumulations', i.e. the amount of rain that has fallen in the previous hour up to the labelled time. FWIW, the closest I can get to 3.3" for the source given is 2013-06-07 05:51 - 2013-06-08 05:51 (3.19"); not far off given the NWS defined rainfall day is 0700-0700.
Kieran Hunt
CC BY-SA 3.0
2017-06-16T16:13:43.817Z
@KieranHunt In addition to a source for 0700-0700, I would be interested in your thoughts about how to interpret the values I've added (for hours 06 and 07) in the edit.
Robert McDonald
CC BY-SA 4.0
2022-01-25T02:16:09.823Z
Looking back, I'm guessing the differences in your algorithm were from precip coming in between 2351 and 0000.  Which I'm guessing end up being counted in the day of for recordkeeping, but would next be reported in the 0051.
JeopardyTempest
CC BY-SA 4.0
2022-01-25T02:42:33.760Z
I think that it can be a real challenge to matching metar to climate reports (as metar will do 6/24 hour totals at 51ishZ [and not necessarily at midnight], whereas climo is midnight to midnight I believe).  I'm not sure the answer... you could try contacting the director of wxchallenge.com where we often came to such an issue and see if he has any input on it.
JeopardyTempest
<meteorology><measurements><precipitation>
How are daily precipitation totals computed?
Robert McDonald
# How are daily precipitation totals computed?

(Asked by: username_0 on 2017-06-15)

I would like to use [ASOS data from Iowa State University](https://mesonet.agron.iastate.edu/request/download.phtml) to compute daily rainfall totals for specific locations. Using ASOS, I am unable to match the official NWS totals. I am assuming that the definition of a day is midnight to midnight, local time.

For example: [KLGA had a record rainfall total of 3.33"](https://www.weather.gov/media/okx/Climate/Almanacs/LGA/lgajun.pdf) on June 7, 2013. An excerpt of the ASOS data covering June 7 is below. The "D" and "H" columns are EDT. It appears that rainfall totals are cumulative and reset hourly at 51 minutes (see hours 12 and 13 EDT for example). But I am unsure how to interpret certain cases. What do I do with hour 21, which reports 0.21" at 36 minutes, 0 at 48 minutes, and 0.24" at 49 minutes. Does that 0 denote a reset prior to 51 minutes, implying a total of 0.45" for that hour? Or does it indicate something else, such as a temporary cessation?

The general questions are: a) how does one parse the p01i column, and b) should it be possible to use ASOS precipitation data to match official NWS totals? Thanks!

[Excerpt from ASOS data:](https://mesonet.agron.iastate.edu/cgi-bin/request/asos.py?station=LGA&data=all&year1=2013&month1=6&day1=6&year2=2013&month2=6&day2=8&tz=Etc%2FUTC&format=comma&latlon=no&direct=no&report_type=1&report_type=2)
`GMT M D H M p01i
...
2013-06-07T16:23:00Z 6 7 12 23 0.11
2013-06-07T16:43:00Z 6 7 12 43 0.19
2013-06-07T16:51:00Z 6 7 12 51 0.21
2013-06-07T17:35:00Z 6 7 13 35 0.18
2013-06-07T17:51:00Z 6 7 13 51 0.22
...
2013-06-08T01:16:00Z 6 7 21 16 0.18
2013-06-08T01:29:00Z 6 7 21 29 0.21
2013-06-08T01:36:00Z 6 7 21 36 0.21
2013-06-08T01:48:00Z 6 7 21 48 0
2013-06-08T01:49:00Z 6 7 21 49 0.24
2013-06-08T02:47:00Z 6 7 22 47 0.22
2013-06-08T02:51:00Z 6 7 22 51 0.22
2013-06-08T03:51:00Z 6 7 23 51 0.11
2013-06-08T03:58:00Z 6 7 23 58 0`

**Edit:** See below. Note that the value of p01i at 6:59 (0.01") is less than that at 6:51 (0.05"), and greater than that at 7:40 (0"), which in turn is less than that at 7:51 (0.09"). What exactly is being reported here?

`GMT M D H M p01i
2013-06-07T10:51:00Z 6 7 6 51 0.05
2013-06-07T10:59:00Z 6 7 6 59 0.01
2013-06-07T11:40:00Z 6 7 7 40 0
2013-06-07T11:51:00Z 6 7 7 51 0.09`

**Edit #2**: @username_2 confirms the importance of 51 minutes past the hour. I have an algorithm that (almost!) works. Assume:

* The day is measured from midnight to midnight local time, *without* a DST adjustment. So in June, LGA remains at -0500.
* Precipitation totals are accumulated to 51 minutes each hour

[The official daily 2013 rainfall totals for June 2, 3, 6, and 7](https://www.wunderground.com/history/airport/KLGA/2013/6/16/MonthlyHistory.html?req_city=KLGA&req_state=NY&req_statename=New+York&reqdb.zip=11371&reqdb.magic=5&reqdb.wmo=99999&MR=1) are 0.11, 0.96, 0.10, 3.33, 0.79. Using the algorithm above with the ASOS data for the same days yields 0.11, 0.96, 0.10, 3.32, 0.80.

**Tags:** meteorology, measurements, precipitation

> **Comments:**
> **username_1**: They are 'hourly accumulations', i.e. the amount of rain that has fallen in the previous hour up to the labelled time. FWIW, the closest I can get to 3.3" for the source given is 2013-06-07 05:51 - 2013-06-08 05:51 (3.19"); not far off given the NWS defined rainfall day is 0700-0700.  
> **username_0**: @username_1 In addition to a source for 0700-0700, I would be interested in your thoughts about how to interpret the values I've added (for hours 06 and 07) in the edit.  
> **username_2**: Looking back, I'm guessing the differences in your algorithm were from precip coming in between 2351 and 0000.  Which I'm guessing end up being counted in the day of for recordkeeping, but would next be reported in the 0051.  
> **username_2**: I think that it can be a real challenge to matching metar to climate reports (as metar will do 6/24 hour totals at 51ishZ [and not necessarily at midnight], whereas climo is midnight to midnight I believe).  I'm not sure the answer... you could try contacting the director of wxchallenge.com where we often came to such an issue and see if he has any input on it.  

---

## 2 answers

### Answer by username_0 on 2017-06-20. Score: 2 | Accepted answer

I am grateful to Daryl Herzmann at Iowa State, who wrangles data at the [Iowa State Environmental Mesonet](https://mesonet.agron.iastate.edu/) for providing an off-exchange answer.

* Synoptic reset times are between 51 and 57 minutes past the hour, depending on the site. A possible way to automate the use of ASOS data is to find the modal minute value in the data. This seems highly likely to be the reset minute.
* The most quoted daily rainfall total is measured midnight to midnight, local standard time, by summing the synoptic hourly total. Because it is standard time, DST is ignored.
* I have created [a github site](https://github.com/rmcd1024/daily_precipitation_totals/) that includes R code to compute daily precipitation totals from ASOS data. This code:

  + Uses the modal minute as the ASOS reset minute
  + Converts the time from GMT to local
  + Subtracts 3600 seconds if DST is in effect

Daryl has a [presentation that discusses precipitation measurement](https://mesonet.agron.iastate.edu/present/130903_isu/isumet_fall2013_web.pdf). Thank you Daryl!

> **Comments:**
> **username_3**: I'm still not sure why you want to account for DST. What's the advantage or reason for that?  
> **username_0**: Think about what happens when you switch from standard to DST. In New York you go from GMT - 0500 to GMT -0400. At 2am it becomes 3am. In the Fall you go from 2am to 1am. What do you with precipitation between 2am and 3am in the spring, or between 1am and 2am in the Fall? You've got 23 and 25 hour days. I'm not saying you can't handle this in some way, but it seems much cleaner to just ignore DST.  
> **username_2**: Suggest you accept this answer, as it's a great resource.  I've followed Daryl for a long time, he has some superb information.  
> **username_0**: @username_2 I'm not sure what you're suggesting. I did accept my answer which cites Daryl.  
> **username_2**: Sorry for the trouble, must've misseen it.  Thanks for taking the time to make the answer (and respond to my aloof comment!)  

---

### Answer by username_2 on 2017-06-16. Score: 2

Typical synoptic (hourly) obs come in about 51 past the hour (sometimes a couple minutes off). The other reports you're seeing are generally subops (SPECIs) which generally only report precip since the last ob given, but the total of which should always be reflected in the hourly.

So for 2136/2148/2149 timed obshour... you just use the 0.24 from 2149, and it should include the others in it (so skip the others that would lead to double-counting).

On the other hand, the 659 ob being smaller than the 651 ob makes sense... as 659 is in the NEW hour... so would be reflected in the 751 ob (which is indeed higher).

I didn't get a chance to look too closely, but looks like all of these are unfortunately altered forms of the data. I believe typical full data should have METAR or SPECI in it to indicate which obs you want?

But no big deal, if you look back at [the rawer-looking data you gave](https://mesonet.agron.iastate.edu/cgi-bin/request/asos.py?station=LGA&data=all&year1=2013&month1=6&day1=6&year2=2013&month2=6&day2=8&tz=Etc%2FUTC&format=comma&latlon=no&direct=no&report_type=1&report_type=2), looks like you can find which ones you want by looking for the ones with SLP reported right about the end. Or, even better, just look for the 6\*\*\*\* fields right about the end, which are the 6 hour total precipitation. Just add the four of those up, and you'll have the daily total.

If you're trying to accomplish all this in Excel, some formulas could be worked up to automatically take what you need from the day's data, or you could use a regex in [any](https://regex101.com/) of the variety of online regex testers. Or writing some sort of script could save a lot of time if you're downloading a lot of data. But the rawer data is often safer and more easy to work with.

I think I used a page like [this](http://www.met.tamu.edu/class/metar/quick-metar.html) for more info back in the day when I had to do it.

> **Comments:**
> **username_0**: Thank you! The confirmation of 51 minutes past the  hour is helpful but I still can't find a source.  The other wrinkle is that  the daily precipitation totals seem to ignore daylight savings time. With this change, which I also can't find documented anywhere, the totals most days exactly match the official totals.  
> **username_0**: I should have mentioned that you are correct that the data I presented was "altered". I did this to clarify the question. The actual ASOS data from Iowa State has the raw METAR strings and numerous additional fields, some of which, such as precipitation, are obviously derived from the METAR.  
> **username_2**: No worries, I thought one of the other sites you'd used presented it that way.  Not a problem, helpful :-)  I tried to find a source for the 51ish info too.  Some suggested it's more like 55.  Think it may have even varied over time or by countries/regions.  But 51 or 52 is the number I'm generally used to over the past 15 years of viewing metar :-)  Indeed looks like you are right that the 6 hourlies won't be useful, because they're 0/6/12/18Z, whereas indeed midnight to midnight won't match that.  
> **username_2**: I believe it's midnight to midnight regardless of DST or not (which is slightly intriguing, because it means the period has subtly shifted for a few weeks in fall/spring based upon DST changes through the years, though honestly the impact on highs/lows/etc is probably trivial)  
> **username_0**: I tried midnight to midnight local time but I can't match daily precipitation totals unless I undo DST and keep the LGA time offset at -0500. Using midnight to midnight allowing DST, the daily totals I compute are off. Documentation would be preferable to this kind of reverse-engineering!  
> **username_0**: I think my question is resolved, see the top of my original post. You might be interested in the linked presentation there. I was thinking more about DST in daily rainfall calculations and concluded that precipitation totals probably had to ignore it, because otherwise one hour would be missed and another double-counted every year. Or there would be some other funky workaround. Again, thanks for your responses!  
> **username_2**: @rmcd no problem, glad you got it worked out.  I would suggest you revert the question to your earlier version, as others coming here may not be able to recognize the problem you had as easily.  And then post your fixes as an answer and accept it so others can see what worked.  That way it remains question and answer :-)  
> **username_3**: Interesting. In Australia the standard day for weather measurements ends at 9:00 AM. I believe this is primarily done because it is hard to get people to make manual measurements at midnight. It does complicate database queries. I agree with the suggestion to write a script or function. Daylight time is ignored because otherwise the length of the day would change.  
> **username_3**: Just another comment: If it makes a difference to your analysis whether rain fell 10 minutes before midnight or 10 minutes after, you'd better start propagating your uncertainties!  
> **username_2**: @username_3, that's a strange one.  That would mean your morning low is actually recording as yesterday???  Plus sunrise isn't until almost 8 this time of year in places like Heywood and Hobart, it seems one cold night would set two separate low temps.  Maybe related to Australia being between UTC+8 and UTC+10 (though not UTC+9 ironically)???  In the US we do choose alternate times, like 12z-12z for tornadoes, but all in a quest to best delineate separation so one day's events don't improperly reflect as the next day's.  9:00 AM to 9:00 AM for temps wouldn't seem to do that.  
> **username_0**: @username_2: I've converted the question and posted an answer. Thanks for the suggestion. I've also posted R code to a github site.  
> **username_3**: By moving the end of the day later on the clock, I think you are less likely to have a cold night split between two days. Just think of it as the day starting when you get up in the morning and ending when you get up the next day. Dawning of a new day and all that. Seems to me shortly after sunrise makes a lot of sense.  
> **username_2**: @rmcd: Awesome!  Very passionate about working to improve all our learning, so much thanks :-)  

---

