Trevin Beattie writes:
> The *BSD FAQ says something about the way to set your kernel options to
> correct this behaviour, but it isn't clear on whether both the config file
> and /etc/localtime should be set or just one of them.  I haven't had time to
> play with the recompiling my kernel yet...

1) The right way to set your timezone is with the userland timezone
   stuff invoked by /etc/localtime being set.

2) From the options.4 man page

     options TIMEZONE=integer
     The kernel (and typically the hardware battery backed-up clock on those
     machines that have one) keeps time in UTC (Universal Coordinated Time,
     once known as GMT, or Greenwich Mean Time) and not in the time of the lo-
     cal time zone.  The TIMEZONE option is used on some ports (such as the
     i386) to tell the kernel that the hardware clock is offset from UTC by
     the specified number of minutes. This is typically used when a machine
     boots several operating systems and one of them wants the hardware clock
     to run in the local time zone and not in UTC, e.g.  TIMEZONE=300 means
     the hardware clock is running US Eastern Time (300 minutes behind UTC),
     and not UTC.

           HISTORICAL NOTE: The TIMEZONE option at one time was used to set
           the kernel's idea of what time zone the system was operating in --
           this information was returned by gettimeofday(2).  Time zone infor-
           mation is now managed by user space software based on the contents
           of the /etc/localtime file or the TZ environment variable.  (See
           zic(8),  tzfile(5),  and tzset(3) for details).  This usage of the
           TIMEZONE option is now obsolete.

     options DST=[0|1]
     On some ports (such as the i386) that permit offsetting the system's
     hardware real time clock with the TIMEZONE option (see TIMEZONE above)
     the DST option being set to one indicates that the hardware clock real
     time clock is set for ``daylight savings time'', and that because of this
     60 minutes should be subtracted from the TIMEZONE value (60 minutes being
     the standard DST correction.) The effect of this on such ports is thus
     identical to simply subtracting 60 from the value of TIMEZONE, and the
     use of the option is thus purely aesthetic in nature.

           HISTORICAL NOTE: Long ago, ``daylight savings time'' computations
           were made in the kernel and not in user space.  The DST option was
           used at that time to set the kernel's idea of whether DST informa-
           tion should be returned by gettimeofday(2).  As with TIMEZONE
           (which see), the moving of timezone handling from the kernel to us-
           er space libraries has obsoleted the old usage of this option.