Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: st: Problem with the time
From
Gmail <[email protected]>
To
[email protected]
Subject
Re: st: Problem with the time
Date
Thu, 14 Apr 2011 10:55:54 +0200
You are right - I thought about it twice:
having an own date type has some advantages but many more disadvantages
let alone version changes and resulting imcompatibilities.
Am 14.04.2011 10:10, schrieb Nick Cox:
There are languages in which dates are distinct data types, but in
Stata the idea is
to hold a date in an appropriate numeric data type and to provide a
rich set of date formats and conversion functions. It would be pretty
bizarre and inefficient to insist that yearly dates must be converted
to milliseconds just because some uses require ms.
Actually, it is entirely possible to work outside Stata's date system
even when using dates.
For example, with daily meteorological data, it is customary to move
back and forth between daily, monthly and yearly resolution and having
separate day -- month -- year variables is the best way to do that.
Having a single date variable that is mdy(month, day, year) is
essential for some purposes but would frustrate many others.
Nick
On Wed, Apr 13, 2011 at 5:54 PM, Guido Lüchters
<[email protected]> wrote:
Dear Nick
yes this is completely clear
but sometimes i am thinking: what if there was one internal date
representation within stata
On the other hand: the stata form is most flexible in respect to
import date values
like study-time in any unit
so pros/cons
But this time i was just not prepared
*
* 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/
*
* 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/