[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

From |
vwiggins@stata.com (Vince Wiggins, StataCorp) |

To |
statalist@hsphsun2.harvard.edu |

Subject |
Re: st: RE: AW: AW: Problems with %tw when date() is used to create a date variable |

Date |
Fri, 06 Nov 2009 12:27:08 -0600 |

Joachim Landstrom <joachim.landstrom@fek.uu.se> has been asking about handling weekly data in Stata and is having particular trouble with the fact that Stata enforces 52 weeks in every year. Stata weeks are invertible and we don't want to lose that property. If we just counted weeks from 1960w1, then you could have 53 weeks in a year, but you couldn't know what year in which a week occurs! Not only that, but you would need to tell Stata what day you would like weeks to start on. We took the equally awkward solution that weeks restart in each year, but now you get weeks that are not all 7 days long (both the beginning and ending week in most years). At least these weeks are invertible with other time units. If Joachim has daily data he observes only once per week (say every Monday), then he can leave his time unit as daily, but tell Stata that they are observed only every 7 days. . tsset mydate , daily delta(7) Even if Joachim's dates are not all observed on the same day, so long as they are observed only once in each week, it is not too difficult create a time variable where we pretend they are observed on the same day each week. Typing, . gen long wkdate = floor(mydate/7) * 7 + 3 sets the dates to their prior Monday. The -delta(7)- in . tsset wkdate, daily delta(7) then tells Stata that the delta between dates is 7 days. So, for example, if we type, . gen lagx = L.x each value of lagx is the the value from the previous Monday -- a 7 day lag. All of Stata's time-series operations will enforce the the 7-day delta. -- Vince vwiggins@stata.com ------------ Original message --------------------------- Subject: st: AW: AW: Problems with %tw when date() is used to create a date variable Sender: owner-statalist@hsphsun2.harvard.edu How nice Martin! I does indeed solve my problem, but raises another concerning years having 53 weeks. When I convert my date values into weekly values as you proposed I end up having duplicates of week 52 for those years that have 53 weeks (such as e.g., 1980, 1985, 1991, 1996, 2002, and 2006). The Stata week values also appear in duplicates so it is not just an issue of formatting. I presume this will pose a problem for me when I tsset the data and start to run regressions on lagged values. What to do with the duplicates (a side issue is of course why does not Stata recognize the 53 week years)? Is there a workaround if needed (my dataset is really on weekly basis so there is no option to run the analysis on daily basis. I could of course run the analysis on monthly basis but I will then loose too much information and hence it is also out of the question. . . /Joachim -----Original Message----- From: owner-statalist@hsphsun2.harvard.edu [mailto:owner-statalist@hsphsun2.harvard.edu] On Behalf Of Martin Weiss Sent: Friday, November 06, 2009 10:41 AM Subject: st: AW: AW: Problems with %tw when date() is used to create a date variable <> See the conversion in action in the last line... ************* clear* inp str10 dates "12/31/1974" end compress gen myDate = date(dates, "MDY") format myDate %td list, noobs //wrong di %tw myDate //correct di %tw wofd(myDate) ************* HTH Martin -----Ursprüngliche Nachricht----- Von: owner-statalist@hsphsun2.harvard.edu [mailto:owner-statalist@hsphsun2.harvard.edu] Im Auftrag von Martin Weiss Gesendet: Freitag, 6. November 2009 10:37 An: statalist@hsphsun2.harvard.edu Betreff: st: AW: Problems with %tw when date() is used to create a date variable <> Not a riddle! -format-ting does not change the underlying value of the date variable, only how it is -display-ed. To switch from daily to weekly frequency, you want to use the conversion functions, as in ************* help dates_and_times, mark(converting) ************* HTH Martin -----Ursprüngliche Nachricht----- Von: owner-statalist@hsphsun2.harvard.edu [mailto:owner-statalist@hsphsun2.harvard.edu] Im Auftrag von Joachim Landström Gesendet: Freitag, 6. November 2009 10:37 An: statalist@hsphsun2.harvard.edu Betreff: st: Problems with %tw when date() is used to create a date variable Hi all, I have encountered a strange problem that I do not know how to solve of if there is a bug somewhere. The problem is as follows. From a string value (such as e.g., 12/31/1974) I create myDate using date. The string value 12/31/1974 thus becomes myDate value 5478. Finally I format the myDate value as e.g., %td or %tw. When I compare myDate with the original string I find a one-to-one correspondance such that the myDate shows the same date as do the original string (i.e., when the original string is 12/31/1974, the myDate %td format is 31dec1974). However when I instead format myDate as %tw I find a completely different result. E.g., the example 12/31/1974 then becomes 2065w19. . . Something must be very wrong and I appreciate any suggestion to solve this riddle. The code is as follows. generate myDate = date(dates, "MDY") format myDate %td I have also tested to use mdy() to create myDate (which takes a few more lines of code) and find identical results. Regards Joachim ___________________________________________ Joachim Landstrom Assistant Professor Department of Business Studies Uppsala University, Sweden * * For searches and help try: * http://www.stata.com/help.cgi?search * http://www.stata.com/support/statalist/faq * http://www.ats.ucla.edu/stat/stata/

**Follow-Ups**:**Re: st: RE: AW: AW: Problems with %tw when date() is used to create a date variable***From:*Joachim LandstrÃ¶m <joachim.landstrom@fek.uu.se>

- Prev by Date:
**Re: st: CPU usage for Stata loops (Windows)** - Next by Date:
**Re: st: RE: AW: AW: Problems with %tw when date() is used to create a date variable** - Previous by thread:
**st: moptimize within moptimize?** - Next by thread:
**Re: st: RE: AW: AW: Problems with %tw when date() is used to create a date variable** - Index(es):

© Copyright 1996–2023 StataCorp LLC | Terms of use | Privacy | Contact us | What's new | Site index |