Am 04.02.2019 um 12:55 schrieb Artur T.: > Dear all, > > I've got two example dataset where time-units are decoded as YYYY-MM-DD. > > I am just puzzled that in case the time-variables is named "z" > everything works fine (see data1.csv). > > However, once the column name is "DATE" (see data2.csv), I obtain the > following error as variable "DATE" is no part of the dataset -- at > least it doesn't appear in main window. I think that's because the special words "obs" and "date" (and possibly others I'm forgetting right now) signal a datestamp to gretl. And that is by definition not a variable to be imported, but meta information in a sense. That's why it only works with "z" instead.

However, I agree that there's a gap here: I guess if it were a pure time series it would work fine. But since it's a panel and the dates are repeated, gretl seems to give up and just imports as-is (undated). But in this situation, we'd like to get the "DATE" column as well, for further use in 'setobs' as you showed.

So yes I think it would be nice if gretl imported all the columns in the text file in case some automatic structure recognition fails.

On Mon, 4 Feb 2019, Artur T. wrote: > Am 04.02.19 um 13:24 schrieb Sven Schreiber: >> Am 04.02.2019 um 12:55 schrieb Artur T.: >>> Dear all, >>> >>> I've got two example dataset where time-units are decoded as >>> YYYY-MM-DD. >>> >>> I am just puzzled that in case the time-variables is named "z" >>> everything works fine (see data1.csv). >>> >>> However, once the column name is "DATE" (see data2.csv), I obtain >>> the following error as variable "DATE" is no part of the dataset -- >>> at least it doesn't appear in main window. >> >> I think that's because the special words "obs" and "date" (and >> possibly others I'm forgetting right now) signal a datestamp to >> gretl. And that is by definition not a variable to be imported, but >> meta information in a sense. That's why it only works with "z" instead. > > True, I remember that some terms are reserved. > >> However, I agree that there's a gap here: I guess if it were a pure >> time series it would work fine. But since it's a panel and the dates >> are repeated, gretl seems to give up and just imports as-is >> (undated). But in this situation, we'd like to get the "DATE" column >> as well, for further use in 'setobs' as you showed. There's an option (not documented, but should be) to handle this case: if you say open filename.csv --all-cols gretl will treat all columns as data and not try to do anything special with the first one.