Statalist The Stata Listserver


[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: decimal years


From   "Austin Nichols" <[email protected]>
To   [email protected]
Subject   Re: st: decimal years
Date   Fri, 11 Aug 2006 14:58:28 -0400

Nick--
Your correction was already in my code, but on rereading, I can see a
different error in my code:
gen d=max(round((ev-y)*yl,1),1)
should read
gen d=int((ev-y)*yl)+1
under the prevailing assumption that the fractional part of a year
represents days, hours, minutes, seconds, &c. elapsed since the ball
dropped in NYC (sidestepping issues of time zone or whether Times
Square revelry existed in that year).

The use of the int() function prevents a time at some point during the
latter half of the day from being mapped to the next day.

That is, 1960.0013 is .0013 years after 12am on 1/1/60, or .4758 days
later, or January 1, 1960 at 11:08:31am. 1932.288 is April 15, 1932 at
9:47:31am.

clear
input double event1
1932.288
1932.998
1959.999
1960
1960.0013
1960.0014
1960.0044
end
gen y=floor(ev)
gen yl=doy(mdy(12,31,y))
gen d=int((ev-y)*yl)+1
gen nd= mdy(1,1,y)+d-1
format nd %d
l, noo clean

My advice about ignoring all the above and instead using the obs# as
the variable in -tsset obs- stands, however.  In particular, I don't
believe that 1932.288 is intended to represent April 15, 1932 at
9:47:31am, but instead someone took April 14, turned that into the
105th day of the year (where 1/1 is the first day) and then divided
105 by 365 and rounded to .288, which set of operations is not
everywhere invertible.  To merely preserve order, I reiterate:

sort event1
gen obs=_n
tsset obs
*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



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