Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.
From | "Liao, Junlin" <junlin-liao@uiowa.edu> |
To | "statalist@hsphsun2.harvard.edu" <statalist@hsphsun2.harvard.edu> |
Subject | RE: st: best practice for dates and times |
Date | Mon, 21 Feb 2011 15:01:12 +0000 |
I see. I read the documentation. But when it comes to actual usage, I forgot. I thought -clock- or -Clock- would be smart enough to figure it out by itself. For those with type setting in float, the newly generated variables should be specified as double. I think there again is a chance for Stata to get smart. Tx, Junlin -----Original Message----- From: owner-statalist@hsphsun2.harvard.edu [mailto:owner-statalist@hsphsun2.harvard.edu] On Behalf Of Nick Cox Sent: Monday, February 21, 2011 8:48 AM To: 'statalist@hsphsun2.harvard.edu' Subject: RE: st: best practice for dates and times StataCorp itself is explicit and emphatic about recommending -double-s to hold date-times of the standard form in which the unit is milliseconds. That's been so since the new date-time system was introduced in Stata 10 in 2007. So, there is no issue or controversy in this particular case, as should be clear to anyone reading the documentation. See, e.g., help for dates_and_times. Nick n.j.cox@durham.ac.uk Liao, Junlin Thank you for the reply. I had read and tried to use the blog post you suggested. That's why I finally choose to simply use string variable to import dates and times. Then you can forget about all the differences in different packages. One caveat, the issue of float vs. double also plays here. The float data type will misrepresent the times for certain values. The actual difference may be in seconds or mili-seconds, but there will be a visual difference when formatted in a meaningful way. Nick Cox On Sat, Feb 19, 2011 at 8:08 PM, Nick Cox <njcoxstata@gmail.com> wrote: > The solution depends on the problem. Sometimes, it is easier to import > numeric variables and then convert them to Stata dates. This can be > very easy. See for example > > http://blog.stata.com/2011/01/05/using-dates-and-times-from-other-soft > ware/ > > Sometimes it is easier to import string variables (which I take it is > what you mean by "text format") and convert them. > > I don't think there is any general better or best solution > independently of how the dates are presented to you and what you want > to do with them. > > Most of the complexity is apparent rather than real. The main > difficulty is wading through the documentation to find the function > you need. Once you've found a solution, it is easy to repeat it. > > Recently I was working with a dataset in which there were five data > columns, Julian date, year, month and day and hour. The people I was > working with didn't care about Julian date, so the main business was > to apply -mdy()- and then -format-. Hour was just 0 or 12, so the most > practical way forward was just to add 0.5 when the measurements were > taken at midday. > On Sat, Feb 19, 2011 at 7:50 PM, Liao, Junlin <junlin-liao@uiowa.edu> wrote: I find that transfer data with dates and times is rather complicated with Stata. Lately I found that importing dates and times in text format and then converting with Stata functions would be the simplest approach. I'd like to hear if others have better solutions. * * 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/ ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ * * 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/