Log in

No account? Create an account
Leap year math blather - The Mad Schemes of Dr. Tectonic [entries|archive|friends|userinfo]

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Leap year math blather [Feb. 29th, 2012|11:43 am]
Here's a question that I have had to answer for work: if you want to compare the weather across multiple years, what do you do about leap days?

Frequently, people dodge around the problem by looking at monthly averages. The months already differ in length by a couple days, so an extra day in February here and there just vanishes into the noise.

But what if you want to look at timescales shorter than a month? What if you need to deal with daily data (which you do if you want to look at phenomena such as heat waves), and you know that decomposing the data into a static background rate (the climatology) plus a time-varying deviation (the anomaly relative to climatology) will make the math work a lot better?

The answer is: switch your (implicit) units from "day of the year" to "orbit angle" by tallying up the days since some base date, dividing by 365.25, and taking the remainder. (Multiply by 2π if you want radians.)

This is because it takes 365.25 days for the Earth to travel once around the sun and return to the same point in its orbit. We only count 365 days in a calendar year, so if you start on March 1st of one year and track the Earth all the way around its orbit, on March 1st of the next year it's actually a quarter-day behind in the track. After another year it's a half-day behind, and after four years, on midnight of February 28th the date is a full day behind the orbital position, so we intercalate an extra day to realign our March 1sts.

What this means is that if you're comparing days year-to-year, once you consider this lag there are actually four different sub-dates for any given date. You shouldn't compare June 30th of 1986 with June 30th of 1988 because they're not the same thing; the orbital position for June 30th in 1986 is actually halfway between the orbital positions for June 29th and June 30th in 1988. In effect, in 1986 you should actually be calling it June 29.5, not June 30. (Note -- it may be tempting to approximate orbital position by just subtracting 0.25 from the day-of-year in each successive year, but that's probably not the best idea. It will sort of work, but only if you count starting from the leap day as your baseline, and it's easy to mess up.)

It might seem that things are now an even bigger tangle, but really all you have to do is switch from thinking of the problem as one where you drop values into successive bins to average them up and instead view it as fitting a curve to a bunch of sampling points at arbitrary locations along the x-axis. Easy-peasy!

(If you really really wanted to use bins, you could still do it. Use four times as many bins, hit only a quarter of them each cycle, and then recombine them with a width-7 triangular window at the end to reduce them back down to 365 bins total.)

I don't expect anybody besides me will find this particularly useful, but sometimes I find it helpful to write out explanations of these kinds of things, and I felt like sharing.

[User Picture]From: jofish22
2012-02-29 06:50 pm (UTC)

is there data for which this degree of accuracy matters?
(Reply) (Thread)
[User Picture]From: dr_tectonic
2012-02-29 07:22 pm (UTC)
Sure. If you're looking at things like the statistics of earliest/latest frost date, or changes in phenology, then one day is a significant fraction of the variability in timing.

It's probably not a big enough error to give flat-out wrong answers, but enough to bias results.
(Reply) (Parent) (Thread)
[User Picture]From: jofish22
2012-02-29 07:28 pm (UTC)
earliest/latest frost date is a really nice idea.

not sure how the shape of one's head might be influenced by being off a day, but there you go.

(yes, i know, but i enjoyed it.)

Edited at 2012-02-29 07:28 pm (UTC)
(Reply) (Parent) (Thread)
[User Picture]From: dr_tectonic
2012-02-29 07:37 pm (UTC)
Dude. Everyone knows that Geminis have overdeveloped parietal eminences because of an overabundance of black bile in the crown chakra.

Edited at 2012-02-29 07:38 pm (UTC)
(Reply) (Parent) (Thread)
[User Picture]From: tdjohnsn
2012-02-29 08:14 pm (UTC)

That nearly made latte shoot out my nose.
(Reply) (Parent) (Thread)
[User Picture]From: dcseain
2012-03-01 03:17 am (UTC)
Darn tootin'! :D
(Reply) (Parent) (Thread)
[User Picture]From: dcseain
2012-03-01 03:56 am (UTC)
Way cool! I understand what you're saying and think it makes great sense.
(Reply) (Thread)
[User Picture]From: fogbear
2012-03-01 05:17 am (UTC)
It may not be useful to me, but it's fun to read!
(Reply) (Thread)
From: thetarnishedowl
2012-03-01 03:24 pm (UTC)
Aren't you then dealing with weather variations within the 24 hour day? If you compare a moment on day.0 to the same moment on day.25, there's a six hour difference on the clock. I suppose if you only deal with 24 hour chunks of time it works. I haven't thought this out. I'm probably wrong. You're smarter than me.
(Reply) (Thread)
[User Picture]From: dr_tectonic
2012-03-01 05:37 pm (UTC)
I'm dealing with daily values here -- things like total precipitation, minimum and maximum temperature, etc.

You're absolutely right, though, that dealing with the diurnal cycle itself is a whole nother layer of complication. Like, does the day run from midnight to midnight local time? Or is the "day" synced up globally to something based on UTC? I'm still trying to figure that one out for my current dataset...
(Reply) (Parent) (Thread)
[User Picture]From: backrubbear
2012-03-03 09:05 pm (UTC)
A different application I worked on simply "solved" the problem by using 28 day months. Since the patterns involved (Internet traffic) tended to follow both seasonal, diurnal and weekly patterns, it was a better comparison than worrying about the fact that a given "month" view may have more or less days.
(Reply) (Thread)