5
$\begingroup$

My problem is that I have weekly data from 2008, 2009 and 2010 but the number of weeks in each of these years are not the same since in we (in Denmark) code the last week in 2009 as 53. This means that I have 52 weeks in 2008 and 2010 but 53 weeks in 2009. Is there some way to make R understand this and treat the time series accordingly. Typically I want it to integrate well with ts, stl, etc. Any help or pointers on this subject would be greatly appreciated.

$\endgroup$
2
  • $\begingroup$ could you share how you decided to proceed to run stl decomposition on your weekly data? I was thinking of maybe averaging w52 and w53 if w53 exists? $\endgroup$ – RockScience May 1 '13 at 10:18
  • $\begingroup$ @RockScience yes that's indeed what I ended up doing. But the whole thing is a thorne in my eye.. $\endgroup$ – Dr. Mike Dec 30 '14 at 13:06
1
$\begingroup$

Packages zoo and xts handle arbitrary time indices. Pick a day of the week that will reflect the discrepancy (late enough to already be in the first week of 2009 yet early enough to be in the last week of 2009) and add it to your date. Functions zoo() or xts() will then accept the date argument after as.Date() is applied to the index with a proper format argument.

$\endgroup$
4
  • $\begingroup$ Thanks for your answer, but I'm not quite sure I get it. For instance the following generates an xts time series that contains week 53: myxts<-xts(rnorm(31), order.by=as.Date("2008-12-15")+0:30) How then do I get it to be in week format? $\endgroup$ – Dr. Mike Aug 10 '11 at 13:56
  • $\begingroup$ Make it myxts<-xts(rnorm(31),as.Date("2008-12-15")+(0:30)*7) $\endgroup$ – Alex Aug 10 '11 at 14:11
  • $\begingroup$ Thank you, that partly solves my problem. Now I only need the xts to play nicely together with stl. But I guess I will end up with the same issue as I started out with since I will then have to convert the xts to a ts which, to my knowledge, does not support non-constant frequencies in the time series. $\endgroup$ – Dr. Mike Aug 10 '11 at 16:55
  • $\begingroup$ Try zoo() instead, the syntax is identical: stackoverflow.com/questions/4833008/… $\endgroup$ – Alex Aug 10 '11 at 19:18
1
$\begingroup$

I struggled with this for a while with a problem I was working on, and in the end decided that it was better to aggregate into monthly data. It (mostly) solves the number-of-weeks problem and it helped smooth out the noise so the results were better anyhow.

An added benefit is that people have a lot of context for months, but not much for weeks of the year, so the data is more meaningful. (I.e. if I say, "April", you have ideas about the weather, holidays, etc, but if I say "week 14", who knows what to associate with that week.)

I say "mostly solves" because each month can have a different number of business days in it, and that does have to be compensated for. (Maybe something as simple as dividing the monthly total by the number of business days and work with a total per day number.)

Of course, you may need weekly data...

$\endgroup$
2
  • $\begingroup$ I couldn't agree more with you. Unfortunately my company deals mostly(if not only) in week-based time series modeling. I believe that using months would be much easier for us though. $\endgroup$ – Dr. Mike Aug 10 '11 at 16:59
  • $\begingroup$ It might still be possible to do something like using average daily value for each week and include the extra days of the year in week 52. Not sure if that's a good idea. $\endgroup$ – Wayne Aug 10 '11 at 17:48

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.