#299 Incorrect Calculations on Series Holding Calendar Information

[Artur Tarassow]

Summary:
When creating a new series holding calendar information in the extended ISO8601 format named obsdate using the built-in functions strptime() and strftime(), simple calculations on obsdate are producing incorrect results. However, when creating a mocked series of obsdate manually, the calculations are correct.

Steps to Reproduce: (see attached script))
1. Retrieve dates from a string-valued series in a timestamp format named timestamp_raw
2. Create a new series obsdate that holds calendar information in the extended ISO8601 format using built-in functions strptime() and strftime() to manipulate the dates.
3. Perform simple calculations on obsdate.

Expected Results:
The calculations on obsdate should produce correct results.

Actual Results:
The calculations on obsdate are producing incorrect results.

Additional Information:
When creating a mocked series of obsdate manually (named y in the attached script), the calculations are correct. This suggests that the issue may lie with how obsdate is being created or manipulated.

Attachments:
A zip file has been attached that includes a sample dataset and a hansl script for replication.

Environment:
This bug occurs with the recent development version of Gretl.

Thanks
Artur

[Riccardo "Jack" Lucchetti]

I wouldn't call this a bug: the weird behaviour you're seeing is a consequence of "obsdate" being a string-valued series in your case.

If you replace the line

series obsdate = strftime(seconds_since_1970, "%Y%m%d")

with

series dstr = strftime(seconds_since_1970, "%Y%m%d")
series obsdate = atof(dstr)

things work ok. The fact that strftime() returns a string-values series, in this case, is mentioned in the help page.

[Allin Cottrell]

The initial report seems to rest on a confusion between the accessor $obsdate, which returns numeric ISO 8601 values, and the series "obsdate" created by assignment from strftime(), which is always in string form.

It would, however, be possible to file some kind of report (bug report or feature request?) suggesting that a statement calling for (string-valued series + numerical value) should produce a types error rather than (at present) returning (numeric code of string-value + numerical value).