I am trying to decompose a weekly time series using the R function 'stl'. One of the important argument of this function is the number of data per cycle. Naturally in this case one would choose 52.

However, my data is published every week, on the same weekday. Hence I have sometimes 53 data per year. Not a big deal, I agree. But I would like to be precise here.

Is there a commonly accepted methodology to treat these situations? I can think of several solutions:

1/ I average the last 2 data in years with 53 data?
2/ I average the last 2 or the first 2 data in years with 53 data? (depending on when we are in the year)
3/ I add an extra datapoint in years with 52 years?


1 Answer 1


My experience is that people brush this kind of complication under the carpet, or at least it seems typically not mentioned in literature. The awkward problems of the year being 365 or 366 days -- and to the point here, it not being 364 = 7 * 52 days -- are important but not widely considered interesting!

If within-week variation were your only problem, then you could just look at day of the week as a predictor. Although you don't spell it out, I sense, however, that you also have seasonality and possibly trend, else why be interested in STL?

You don't spell it out either but I guess wildly at some economic data here. I also focus on Western calendar years.

I can't say I like any of the three solutions you suggest. What's more, I predict that if you chose any you would then get criticism from reviewers for arbitrary and indeed biased choices. (It's empirically important that the last two weeks of the year are special too, at least in societies that celebrate Christmas as a festival.)

I have not used STL and would tend to try to handle problems like this in a top-down manner. With daily data and days indexed 1 .. 365 or 366 I have used

fraction of year = (day of year - 0.5) / (365 or 366)

as a predictor. In any decent software you can identify leap years and non-leap years automatically, e.g. by 29 Feb being a valid date or not, or some day-of-year function being 366 or 365. I can tell you how to do that in Stata, but not in R.

Then day of the week is another predictor (e.g. as a set of indicator variables).

However, my experience is mostly with environmental data for which some sine and cosine terms often yield a fair approximation to annual cycles. That's typically not good enough if your data were economic.

There are some very elaborate seasonal adjustment programs intended for economic data that may do much more. I can't advise on details, but they tend to have special handles for holidays and unusual days, depending on what society they are constructed in.

  • $\begingroup$ "My experience is that people brush this kind of complication under the carpet" Totally agree with you. I don't know which elaborate seasonal adjustment programs you are referring to. The one I think is the most widely used (X12/13-arima from US Census Bureau) is simply not supporting weekly data. Only monthly and Quaterly. That's another way to deal with the proble ;) $\endgroup$ May 7, 2013 at 8:34
  • $\begingroup$ X12 etc. are what I had in mind but could not name. $\endgroup$
    – Nick Cox
    May 7, 2013 at 8:38
  • $\begingroup$ So basically your advice is to try to use a seasonality analysis that doesn't require a fixed number of data point per cycle. (replace stl by sinusoidal predictor for instance). This doesn't exactly answer my question but it is definitely a nice input and I think this could be generalized to any seasonal component, even not simply sinusoidal, thanks! $\endgroup$ May 7, 2013 at 8:46
  • 1
    $\begingroup$ In short, yes. If you have just weekly data and not daily then you can characterise each week by its midpoint. The analysis doesn't have to be sinusoidal, but if you smooth or model then it's important that predictions for beginning and end of year should be identical. That's guaranteed by sinusoids and has to be arranged otherwise. $\endgroup$
    – Nick Cox
    May 7, 2013 at 8:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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