Re: GDate

[Josh MacDonald <jmacd CS Berkeley EDU>]

I looked at the gdate module in CVS, it looks nice.  Anyway, I think
several things are missing: direct manipulations of ISO-8601 dates,
and unification of these functions with more accurate time divisions
(hours, minutes, seconds).

Formatting other than ISO-8601 should be strongly discouraged.  I don't 
think a strftime function should be included, rather a funcion to convert a 
time-string to a GDate and a function to convert a GDate to a ISO-8601 
formatted string.  Perhaps RFC-822 is desirable, but anyone who uses 
anything other than ISO-8601 today should not be, anyway.  I highly 
recommend Paul Eggerts date/time parsing functions which can be located 
in diffutils.  He's very knowledgeable about these things--
<eggert@twinsun.com>.

Also, without digging into the implementation, what is:

	g_date_set_parse

Or more precisely, how does it parse?  This is tricky stuff, again
I recommend Paul Eggert's code.

And support for less-accurate forms of date types seems not very 
useful.   I like the Java interface here, have you looked at it?  I
think it might be nicer.  Why not include times in the GDate structure?
A date without a time is useless since it may be Sunday in California
and Monday morning in Europe.  Timezone's impact the date, and therefore
time impacts the date.  Times must be included for this interface to
be acceptable.  I think the Java interface should be cloned.

I respect Steffen Beyer's code very much, and I'm sure all the Julian 
calendar stuff works, but without more accurate timing, knowing the 
correct date does nothing for me.

-josh

Quoting Havoc Pennington (rhpennin@midway.uchicago.edu):
> 
> On Tue, 24 Nov 1998, Tor Lillqvist wrote:
> > 
> > Hmm, that would be possible. Output for instance 1996-11-24 in %x
> > format and look for what order the strings "1996" (or "96"), "11", and
> > "24" are in the output.
> 
> I'm going to implement this then. Probably also some way to force a
> particular order (in case I'm in Europe but want to parse US dates, or
> whatever).
> 
> > Hmm, this breaks if the preferred format uses
> > month names. 
> 
> I can make some minimal effort to find %b or %B in the %x output, I guess. 
> If the locale's format is too weird, we are just going to have to give up
> and use a default though. Perhaps people will submit patches to handle
> other cases. (For example, I don't know how or if this will all work in
> Asia.) 
> 
> The only issue is whether g_date_set_parse() works, of course, the rest of
> the library won't depend on this kind of heuristic.
> 
> > (Are there locales that use the Islam or some other
> > non-Gregorian calendar?)
> > 
> 
> If so people will have to send patches, because I have no clue how to
> handle it. :-)  These locales probably don't want to use the library
> anyway, since all the calculations are on Gregorian dates.
> 
> I should point that out: the g_date_* routines project the Gregorian
> calendar backward and forward in time. They don't try to be historically
> accurate (i.e. we are ignoring the fact that the Gregorian calendar has
> only been in use a few hundred years). This makes things much more
> efficient, and is the right thing to do for most modern applications.
> 
> Havoc
> 
> 
> 
> -- 
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with 
>                        "unsubscribe" as the Subject.

-- 
-josh