Am 30.09.21 um 18:27 schrieb Artur T.:
Am 30.09.21 um 17:38 schrieb Sven Schreiber:
> Am 30.09.2021 um 17:29 schrieb Artur T.:
>> Am 30.09.21 um 16:13 schrieb Sven Schreiber:
>>
>>> Then, I'm observing that the result for date_to_iso8601("1984",
"%Y")
>>> is: 19831231. Is this a bug? I would have expected 19840101.
>>
>> Looks like a bug on the gretl side to me.
>
> Right, see Jack's remarks.
>
>
>> Before proceeding with this, Sven: What's the actual value-added of
>> having a function which needs to handle a format such as "1994:1" if
>> "199401" is already supported?
>>
> Well, first of all "1994:1" is what gretl uses for quarterly data, so it
> seems natural. Secondly, things like 199401 are only supported for
> monthly, right? So for "199402" you'd get 19940201, not the needed
start
> of the second quarter 19940701. Or amĀ I overlooking something?
I am just working on a proposal supporting both quarterly and monthly
frequencies. I should be able to finish it today and then let's discuss
that if you agree ;-)
Hi Sven,
I've added a new function named gdate_to_iso8601().
The signature is as follows:
<>
function scalar gdate_to_iso8601 (string date "Date string",
string frequency "Frequency of
observation")
/* This function only supports quarterly date strings as used and
accepted by gretl itself;
basically only patterns like "1999:3" or "1999.3".
</>
Here you find the tests which explain what that function does and is
expected to return:
https://github.com/atecon/calendar_utils/blob/feature/prepare-v03/tests/r...
The supported frequencies are quarterly and monthly data.
Is this what you had in mind?
Artur