[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Location of utility functions.

From: Sergey Poznyakoff
Subject: Re: Location of utility functions.
Date: Sat, 16 Jun 2001 17:18:54 +0300


> 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
-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.
> 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 :^)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]