SAMBA/NEXTSTEP: correcting twice for daylight savings time

SAMBA/NEXTSTEP: correcting twice for daylight savings time

Post by Chris Roehr » Tue, 23 Apr 1996 04:00:00



[Samba-1.9.15p8, NEXTSTEP 3.3/m68k]

Samba seems to be correcting twice for daylight savings time.   My  
configuration sets timediff (in TimeInit, util.c) using the tm_gmtoff field of  
the tm struct which on my system already corrects for DST (it gives the  
difference between PDT and GMT, not PST and GMT).   The TimeDiff function then  
corrects a second time when it returns timediff-DSTDiff(t).

  My fix (util.c, line 422):

#ifdef NEXT3_0
    /*  timediff is the offset of local STANDARD time, not DAYLIGHT time */
    timediff = -tm_local.tm_gmtoff;
    if( tm_local.tm_isdst ){
        timediff += 60*60;  /* set back to STANDARD time */
    }
#elif HAVE_GMTOFF
  timediff = -tm_local.tm_gmtoff;
#else
  timediff = mktime(&tm_utc) - mktime(&tm_local);
#endif

I dunno how gmtoff works on other systems, but the isdst check may want to be  
moved inside the HAVE_GMTOFF bit.

Another minor change (for logging, mainly):   NeXT's strftime does not have %D  
and %T.  Use asctime instead.  Fix: add -DNO_STRFTIME in Makefile or #define  
NO_STRFTIME in includes.h

--

Neuroscience and Computer Science at University of British Columbia, Vancouver
http://www.House.ORG/chris                      http://www.sns.cs.ubc.ca/chris

 
 
 

SAMBA/NEXTSTEP: correcting twice for daylight savings time

Post by Paul Egge » Fri, 26 Apr 1996 04:00:00



> Samba seems to be correcting twice for daylight savings time.

The Samba time zone code is dubious in several minor (but annoying) respects.

Samba invokes mktime on the output of gmtime; this may fail during DST
transitions, since the output of gmtime may not be a valid localtime if
it falls in a spring-forward gap.

Samba seems to assume that whenever the localtime GMT offset changes,
tm_isdst changes and vice versa.  This assumption isn't true.
Sometimes tm_isdst changes even though the localtime GMT offset does not change
(for example, this occurred in Portugal on March 31 of this year).
Sometimes tm_isdst does not change though the localtime GMT offset does change
(for example, this occurred in Moscow on January 19, 1992).

Samba seems to assume that local standard time does not change during the life
of the program.  This isn't true in locales that are changing their
GMT offset (e.g. Portugal on March 31).

Samba assumes that DST is always one hour away from standard time.
This isn't always true (e.g. Newfoundland in summer 1988).

The Samba mktime replacement (used if REPLACE_MKTIME is defined)
doesn't handle time zones correctly, and doesn't have the correct
definition of leap years (granted, this won't break until 2100 AD :-).

If I can find the time I'll try to submit a bug report with a fixes;
I'm not an expert on Microsoft's time zone brain damage so it may be
a while.

 
 
 

SAMBA/NEXTSTEP: correcting twice for daylight savings time

Post by Paul Egge » Sat, 27 Apr 1996 04:00:00



> there are some really stupid bugs in the MS code.

Yes, but Samba has bugs independent of Microsoft bugs.
To see this, here are more details about the first bug

The source/util.c TimeInit() code

  tm_utc = *(gmtime(&t));
  tm_local = *(localtime(&t));
  ...
  timediff = mktime(&tm_utc) - mktime(&tm_local);

is not correct in general,
since mktime(gmtime(&t)) sometimes yields -1 on some hosts.
For example, if the current time is 1996-04-07 02:30:00 UTC
and the current timezone is US/Pacific,
then mktime(&tm_utc) yields -1 on some hosts
since 1996-04-07 02:30:00 is not a valid local time in that timezone.

This Samba bug does not exist because of desires to be compatible
with Microsoft timezone bugs: it is a bug in its own right.
And it's not the only such bug in Samba.

Quote:> When a timeentry on the MS client is converted
> to the SMB representation,  
> MS subtracts the current difference to GMT from the
> localtime. Of course, this difference changes when
> a DST transition occurs on the MS side.

Thanks for this description.
It tells me more about the MS client brain damage,
and I need to understand this before I can propose fixes to the Samba bugs.

My understanding of what you're saying is that if the current difference
between localtime and UTC is -7 hours (e.g. US/Pacific right now),
then MS clients subtract 7 hours from localtime for all timestamps,
even though timestamps for last winter are actually 8 hours behind UTC here.

I'll keep this brain damage in mind when I propose fixes to Samba.
If there's any other brain damage like this,
or if my understanding of the brain damage is incorrect,
please let me know.

 
 
 

SAMBA/NEXTSTEP: correcting twice for daylight savings time

Post by Erwin Authri » Sat, 27 Apr 1996 04:00:00


Sorry! My From: address is wrong !

: The Samba time zone code is dubious in several minor (but annoying) respects.

I would rather say the Microsoft time zone code is dubious.

: Samba invokes mktime on the output of gmtime; this may fail during DST
: transitions, since the output of gmtime may not be a valid localtime if
: it falls in a spring-forward gap.

: Samba seems to assume that whenever the localtime GMT offset changes,
: tm_isdst changes and vice versa.  This assumption isn't true.
: Sometimes tm_isdst changes even though the localtime GMT offset does not change
If you experiment with it, you will find out that  
there are some really stupid bugs in the MS code.
What happens is quite obvious:

When a timeentry on the MS client is converted
to the SMB representation,  
MS subtracts the current difference to GMT from the
localtime. Of course, this difference changes when
a DST transition occurs on the MS side.

Just try it out between two Win95 machines where
one machine is in some timezone with DST and the
second machine is in a non-DST zone. You will see
that you get wrong time entries.

If MS would be able to transmit the GMT representation,
we would not need all the DST stuff in Samba.

: If I can find the time I'll try to submit a bug report with a fixes;
: I'm not an expert on Microsoft's time zone brain damage so it may be
: a while.

I think that you should send a bug report to MS, if
you know of a way to do so (Somebody from the list
told me that MS is not interested to hear about Bugs
in Win95).

In the meantime, Samba has to live with this
MS-sh.. and make the best of it.

 
 
 

SAMBA/NEXTSTEP: correcting twice for daylight savings time

Post by Paul Egge » Mon, 29 Apr 1996 04:00:00



>I dunno how gmtoff works on other systems, but the isdst check may want to be  
>moved inside the HAVE_GMTOFF bit.

gmtoff basically works the same on all systems where it exists,
so you're right, the isdst check should be moved inside.

But there's a better way to fix Samba's problem: don't use is_dst or
gmtoff at all, and calculate the GMT offset the same way that Emacs does.
This is a lot more portable.
I'll try to write up a proposed patch along these lines.

 
 
 

1. Daylight Savings Time and SAMBA problem

Andrew, and whomever else is concerned:

I have noticed that the Samba server suite does not observe Daylight
Savings Time, which took effect here in the Eastern U.S. last Sunday.
I am running Samba 1.9.10 on a Linux 1.1.65 server.  The server's time
was automatically updated, and reports correctly as "hh:mm EDT", using
the Unix "date" command.

However, all Samba programs, such as smbstatus, report the standard
time, as if the server's time had not been set forward.

For example, if the Linux server's "date" command reports the time to
be 13:32 EDT, smbstatus will report a connection made at that time as
having been made at 12:32.  Likewise, if I use the Windows95 or WFW 3.11
"NET TIME \\servername" command, they report the server's time as 12:32PM,
rather than 1:32PM.

Thanks for your time - no pun intended!

/--------------------------------------------------\

|              |  CompuServe:  73670,762           |
\--------------------------------------------------/
--
/--------------------------------------------------\

|              |  CompuServe:  73670,762           |
\--------------------------------------------------/

2. explosion simulation

3. <<Time change tonight -- watch that daylight savings check box >>

4. Cisco Netowrk Registrar Migration

5. Dell & Daylight Savings Time

6. recommended hardware for raid 1

7. Daylight Savings Time problems

8. Is it Time for X-10 Security Deluxe?

9. Robocopy, NT, Daylight Savings Time

10. Samba and Daylight Savings

11. Outlook recurring appt glitch-Daylight Savings

12. Database empty after daylight savings, does not refill properly

13. Daylight Savings ends - files on share an hour in future