Re: gdate integration

[Havoc Pennington <rhpennin midway uchicago edu>]

On Tue, 1 Dec 1998, Aaron Digulla wrote:
> Please use 0..6 for the valid days and -1 for the bad day. This way,
> one can work with modulo on week days (well, more easily :-) OTOH,
> months from 1 to 12 look more "natural" than from 0 to 11 :-/
>

I think this is too inconsistent with the rest of GDate... right now all
values are unsigned, with 0 the invalid value... this means g_date_clear
just zeroes the struct. If you did this then one of the values would be
signed, and 0 would be a valid value for it, and it would be sort of
hackish I think. 

You can always subtract 1 if you need to do the modulo thing (though you
probably don't need to, since you can just use the provided functions for
nearly any case I can think of).

Re: Jeff's struct tm comment, I think one of the many reasons struct tm
sucks is the use of numbers starting with 0, especially for months... I've
provided g_date_to_struct_tm precisely so one doesn't have to think about
struct tm. You can go the other way with g_date_set_time().
 
> Thought about this for a while (whether it might be better to move
> to mar, 1st than to feb 28th) but I don't know which is better.
> Moving to the 28th means that you "add" 365 days (the normal length
> of a year), moving to the 1st seems more "natural" (this is the
> 29th in the next year because it follows the 28th...). How are other
> packages solving this ?
>

DateCalc does what I'm doing. The Java API docs say the Calendar::add() 
method "Adds the specified amount of time to the given time field, based
on the calendar's rules" which is pretty uninformative. I agree that it
might make sense to maintain the same day-of-year number. Either way the
function does the wrong thing in some cases though - I don't know. 

Havoc