[pdf-devel] Re: Calendar spans

[Aleksander Morgado]

Hi,

>    I have some questions regarding Calendar Spans in the Time Module:
>
>    pdf_status_t
>    pdf_time_add_cal_span (pdf_time_t object,
>                            const struct pdf_time_cal_span_s cal_span)
>
>    In the function `pdf_time_add_cal_span', the idea is to add to a given 
>    pdf_time_t (stored internally in seconds since Unix timescale origin), a 
>    given time span stored in a calendar way (years, months, days, and so 
>    on). The thing is... this calendar span should be referred to a given 
>    time origin, as the number of seconds in a year or in a month really 
>    depends on the year or the month...
>
> The base date to resolve the span should be the specified point of
> time contained in OBJECT (would be better to name it TIME_OBJECT). In
> other case the function doesnt have sense at all! This should be
> documented in the Refman. entry for the function.

But even if the time origin is fixed, I see a problem: not all the 
months have the same number of days ( who the hell decided this? ). So 
if for example the time object represents January 31st and I want to add 
1 month coming in the calendar span... which would be the resulting 
date? February 28th/29th? March 1st? The same problem happens with years 
if the time object is 29th February and you want to add 1 year in the 
calendar span... which would be the resulting date?

> Hmm. Maybe would be a good idea to reinsert the `sign' attribute in
> the cal time spans: `pdf_time_span_t' can be negative, and the idea
> behind calendar time spans is to reflect the semantics of the opaque
> `pdf_time_span_t' in a human-friendly way.

Ok.

>    BTW, is it really necessary/useful a time span stored in calendar way, 
>    taking into account that it must be referred to a given time origin?
>
> In fact I think that they are really useful for work with
> date-relative time spans. A year is conceptually only one year
> regardless the number of days it is composed of, and "users" like to
> speak in months and years :)

Ok, no problem to keep on with the calendar spans, but we should decide 
the behavior in situations like the one I described above.

-Aleksander