Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: Re: Cannot get date fields to import from PostgreSQL via ODBC


From   Joseph Coveney <jcoveney@bigplanet.com>
To   Statalist <statalist@hsphsun2.harvard.edu>
Subject   Re: st: Re: Cannot get date fields to import from PostgreSQL via ODBC
Date   Tue, 27 Sep 2005 23:23:10 +0900

Dave Ewart wrote:

Ah, interesting: that certainly appears to work, in the sense that it
reads in the dates as strings.

However, this doesn't actually give you 'proper' date variables, does
it?  I realise one can string-splice to pull out the components of the
date, but that's rather tedious.
[excerpted]
Can you suggest a way to 'transparently' import these dates as 'proper'
date variables?  Or at least a way to easily re-type the imported
strings as dates?

--------------------------------------------------------------------------------

Starting with a date variable imported as a string, e.g.,

set obs 1
generate str c = "2004-01-01 19:27:03" ,

then you can re-type it in two lines of code:

generate int c_date = date(substr(c, 1, 10), "ymd")
format c_date %dCY-N-D

If you have a lot of such variables, then use -foreach var of varlist-.  An
ado-file could be easily written around this that would automate this for a
variable list and it could either replace the original string variable with
a date-formated integer variable, or generate new variables with a default
stub or suffix or an optional one.

Check the summary of available commands posted by Nick Cox at the end of
January 2003 www.stata.com/statalist/archive/2003-01/msg00592.html More
might have become available since then; check around.  There are
user-written programs for dates, times and the like, and one might be
available to do this.

Joseph Coveney

*
*   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–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index