Art S. Kagel (Oninit) ha escrito:

Thank you Art.

I have another problem with INTERVALs.

I'm programming in ESQL/C and I really need to interpret the
underlying in_dec (dec_t) data that is part of the intrvl_t structure.

In fact, I already did it. I can succesfully interpret YEAR TO MONTH
and DAY TO SECOND values. But I found an edge case that doesn't follow
the manual, as I understood it.

The dec_t structure contains four fields: dec_exp, dec_pos, dec_ndgts
and dec_dgts. dec_pos gives me the sign, dec_exp gives me number of
digit pairs to count from the left to position the decimal point,
dec_ndgts is the number of significant digit pairs and dec_dgts are
the actual digits.

After retrieving a INTERVAL(3700) YEAR(9) TO YEAR value, I invextend()
it to YEAR TO MONTH (for my own purposes)

          invextend(data, &invl);

I do it like this:

           intrvl_t *data, invl;

           data = (intrvl_t *)var->sqldata;
           if (TU_START(data->in_qual) <= TU_MONTH)
               invl.in_qual = TU_IENCODE(9, TU_YEAR, TU_MONTH);
           else
               invl.in_qual = TU_IENCODE(9, TU_DAY, TU_F5);

           invextend(data, &invl);

When interpreting the resulting invl value, I find that exp is 7,
ndgts is 1 and dgts[0] is 37, but I expected ndgts to be 2.

My routine is interpreting then 3700 days incorrectly as 37 days,
because it only gets one pair of digits (ndgts == 1) from dgts.

What am I missing?

For now, I have worked around it memset()'ing invl to zero before
ivextend()'ing and, since I'm always extending to YEAR_TO_MONTH, I can
safely ignore dec_ndgts and interpret dec_dgts as if it always holds
months. In my example above, I would access dec_dgts[1] even though
dec_ndgts is 1, because I'm sure ivextend() worked and have preset
invl to zero.

Thanks in advance.