noticed that atime on files served by dossrv is wrong.
dossrv builds a Tm structure with Tm.zone=="" and
passes it to tm2sec().
there are other servers, like zipfs using similar code
which i assume would also return wrong time as well but
havnt tested it.
the problem seems to be this:
tm2sec() ignores Tm.zone if its not one of the ones specified
in the timezone variabe. but the manual states:
Tm2sec converts a broken-down time to seconds since the
start of the epoch. It ignores wday, and assumes the local
time zone if zone is not GMT.
as Tm.zone is not explicitely set to "GMT", i think
tm2sec() should specially handle the Tm.zone==""
case the following way:
/*
* Only handles zones mentioned in /env/timezone,
* but things get too ambiguous otherwise.
*/
if(strcmp(tm->zone, timezone.stname) == 0)
secs -= timezone.stdiff;
else if(strcmp(tm->zone, timezone.dlname) == 0)
secs -= timezone.dldiff;
else if(tm->zone[0] == 0){
secs -= timezone.dldiff;
for(p = timezone.dlpairs; *p; p += 2)
if(secs >= p[0] && secs < p[1])
break;
if(*p == 0){
secs += timezone.dldiff;
secs -= timezone.stdiff;
}
}
so basically, if Tm.zone=="", we assume that the local timezone
applies (as stated in the manual). we check if the time falls
in a daylight saving period, otherwise assume normal time
offset. (this should be the reverse of what localtime() does).
this code seems to work ok for dossrv, but i'm not sure of any
unintended side effects.
--
cinap
