On Sun, Jun 23, 2002 at 01:42:35AM +0200, Josef Wolf wrote:
> On Sat, Jun 22, 2002 at 03:01:33PM -0500, Karl Fogel wrote:
> > Personally, I don't have any issue with storing a few extra bytes per
> > string (that is, having weekday names in the repository strings).
> I think I had too much beer today. This must be the reason for my
> confusion. I can understand that you want weekday names and month
> names on user-visible output. But why on hell do you want to _store_
> them in the repo? Why not store in GMT and use localtime() (or some
> apr-aequivalent) for output?
Exactly. We should be storing the dates/times in the repos using a simple
ISO8601 format, in UTC. My preference would be for the DAV format, but as
long as we have a conversion function from repos-string-format to
apr_time_t, then I can do a two-step conversion to the DAV format.
The simple issue is that the repository needs a very rigorous, well-defined
format so that the widest variety of tools can interact with it, using a
well-defined semantics. ISO8601 is the best format available, and a ton of
stuff knows how to use it, so we ought to be choosing that. This means that
people peeking into the database using BDB functions, or fetching props, or
whatever will always see a known format.
[ ideally, the internal FS interfaces would be using an apr_time_t and it is
only when we marshal into BDB would it be converted to an ISO8601 string;
some relational DBs would simply use a time-typed column. this approach is
made difficult, however, by our use of a revision property for the date,
rather than a formalized API. ]
> > My real priority is the first one: make default human-presentation
> > strings as readable as possible, which means including the weekday
> > name and (IMHO) possibly the month name as well.
> Well, this is the job of the input-/output-functions. This has nothing
> to do with the (internal) storage format.
> Hmm, I am not sure whether I should get a new beer ;-)
Well, I'm sure of it. Go have fun :-)
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Jun 23 02:28:20 2002