Re: Location of utility functions.

[Sam Roberts]

Quoting Alain Magloire <address@hidden>, who wrote:
> > 
> > > Allo Sergey, et ou est tu a le monde? 3 hours east of Paris, I take
> > > it...
> > Yes, 3 hours (DST). I live in Odessa, Ukraine..
> 
> Ha!  So I come you know so many languages?

Indeed, I'm the one who's supposed to be bilingual. :-)

> > > If that's true, then I'll buckle to necessity, timezone offset will
> > > have to be carried around outside of struct tm, so I'll add the
> > > int* timezone arg you suggest to parse822_date_time().
> > 
> > To tell the truth, having all time-converting functions accept
> > (struct tm *tm, int *tz) arguments seems to be a clumsy way of doing
> > things. We can, however, declare a
> > 
> > struct mu_time
> >   {
> >      struct tm *tm;
> >      int tz;
> >   }

> I think Sam's idea was to use what the platform offers i.e.
> struct tm is widely use and there is so many functions that uses it
> instean of having another structure. If need be the generated
> struct tm could be use in strftime() etc ..

Right, but I agree that the int* is kind of clumsy, and it also doesn't
allow the timezone abbreviation, should there be one, to be returned
(without yet another argument, anyhow).

Since struct tm doesn't reliable contain timezone info, how about
we just create a seperate structure for that:

struct mu_timezone
{
  int offset; /* seconds east of UTC */
  const char* name; /* abbreviated name of timezone, if known */
};

Also, I'd like to make configure test for the presence of the timezone
extensions in struct tm, so that if present, I'll fill them in, and
if not, I won't. People can always use the above structure, portably,
but if their system actually has timezone info, they will see it.

> Probably did not for see that TimeZone was such a pain 8-).

Not for a second. I just keep learning...

> >  -int parse822_date_time(const char** p, const char* e, struct tm* tm)
> >  +int parse822_date_time(const char** p, const char* e, time_t *)
> > 
> > etc. What do you think?

The thing is, that time_t isn't actually the same info, it tells you
the absolute time, but the date-time is wall clock time. What if I
wanted to analyze my archive of the bug-mailutils to see who posted
the most between 3am and 5am, say? I like when basic APIs don't
narrow the information being passed out, instead they just make
it easy to access.

So, I think I like having the additional argument, but won't make
it just an int. Sound reasonable?

(and thanks for more of the config patches for sieve/, Sergey)

> Unfortunately will not be able to follow discussion this weekend
> going temporary offline.  One of my disk is behaving funny.

It's always the hardware that breaks!

Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)