[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 22:05:28 +0300 |
> 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..
> time_t mu_tm2time(struct tm* tmptr)
> {
> # define MU_INVALID_TIMEZONE (25 * 60 * 60)
> static int mu_timezone = MU_INVALID_TIMEZONE;
>
> /* We don't want to recalculat mu_timezone if we live in London.
>
> Or, maybe we should recalculate each time, what if TZ changed?
Yes, I believe we'd better recalculate it. If someone were reading
mail at the moment his time switches to DST, he would be unaware of
the changes...
>
> How about I:
>
> - Rename mu_mktime to mu_tm2time(struct tm* tmptr).
> - Have mu_tm2time() assume that the tz fields are correct, and NOT
> trash them.
<..snip..>
>
> I have a feeling that you will tell me that struct tm doesn't have
> a tm_gmtoff portably...
That was just what I was going to say :^)
> 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;
}
and use it for passing time information. But maybe we'd better simply
pass time_t *? It contains all the necessary information and could
be converted to struct tm easily. So, for example:
-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?
au revoir,
Sergey
- Re: Location of utility functions.,
Sergey Poznyakoff <=
- Re: Location of utility functions., Alain Magloire, 2001/06/16
- Re: Location of utility functions., Sam Roberts, 2001/06/16
- Re: Location of utility functions., Sergey Poznyakoff, 2001/06/18
- Re: Location of utility functions., Jeff Bailey, 2001/06/18
- commit mailutils, Alain Magloire, 2001/06/22
- Re: commit mailutils, Jakob 'sparky' Kaivo, 2001/06/22
- Re: commit mailutils, Sam Roberts, 2001/06/27
Re: Location of utility functions., Sam Roberts, 2001/06/16