Re: Location of utility functions.

[Sergey Poznyakoff]

Bonjour,

> Pehaps mu_mktime() can be a thin wrapper, it can subtract the
> gmtoff from the hour/minute (mod a 24 hour day), then call mktime().
> After doing the subtraction, the date, and day of week may be wrong,
> however I think that mktime() is supposed to recalculate them
> if they are wrong. I'll try and check. Does this seem portable?

A couple of thoughts about mktime() and the timezone problem. I have
examined the sources of all libc versions that I have access to (these
are libc 5, GNU libc in CVS repository and FreeBSD libc): in each of
them mktime() function calls tzset() and ignores tm_gmtoff field of
struct tm. So I have implemented the function mu_mktime(struct *tm,
int tz), its source is mailbox/mu_mktime.c (I guess your proposition
for it to be mutil_mktime is great, I have just finished commiting the
changes when I got your letter :^). I would also propose that
parse822_date_time(), which also suffers from timezone problem, be:

int parse822_date_time(const char** p, const char* e, struct tm* tm, int *tz);

and that it return the timezone in the location pointed to by its last
argument. To do this it would suffice to:

Index: parse822.c
===================================================================
RCS file: /cvs/mailutils/mailbox/parse822.c,v
retrieving revision 1.12
diff -p -u -w -b -r1.12 parse822.c
--- parse822.c  2001/06/15 02:48:26     1.12
+++ parse822.c  2001/06/16 14:10:26
@@ -1431,7 +1431,7 @@ struct tm
 };
 #endif
 
-int parse822_date_time(const char** p, const char* e, struct tm* tm)
+int parse822_date_time(const char** p, const char* e, struct tm* tm, int *tzp)
 {
   /* date-time = [ day "," ] date time */
 
@@ -1487,9 +1487,11 @@ int parse822_date_time(const char** p, c
     tm->tm_sec  = sec;
 
     tm->tm_isdst = -1; /* unknown whether it's dst or not */
-    tm->tm_gmtoff = tz;
-    tm->tm_zone = tzname;
+
   }
+
+  if (tzp)
+    *tzp = tz;
 
   return EOK;
 }


Any objections?

> So where should utility functions that will be exposed to the user
> of mailbox go? I'd suggest mailbox/mutil.c, with corresponding header
> files, and mutil_*() as functions names, to avoid colliding with imap4d/
> util.c.
<..snip..>
> Anybody want to make an executive decision on this, or have a comment?

I guess it is a good idea. Let Alain give his verdict :^)

-Sergey