Turns out that the US time zones are correct, but the Canadian ones weren’t: I use America/Vancouver as time zone on that box. In order to fix that, I grabbed the ‘northamerica’ time zone source file from the 3.1 release:

$ cd /usr/src/share/zoneinfo
$ cvs up -r netbsd-3-1-1-RELEASE northamerica
$ su -
# make install

Now, everything’s correct.

A less intrusive alternative would be to use the US equivalent of the Canadian time zone (so using America/Los_Angeles would have worked, too).

Thank you very much. Your information was very helpful.

Look here for NetBSD:

http://mail-index.netbsd.org/netbsd-announce/2007/02/27/0000.html

You should be OK.:

Daylight Saving Time Changes: Nothing new for NetBSD

Daylight Saving Time (DST) was extended in a number of countries starting
in 2007. For example, beginning in 2007, most of the USA will begin
Daylight Saving Time at 2:00 a.m. on the second Sunday in March and revert
to standard time on the first Sunday in November. While this has caused a
number of software vendors a lot of headache, NetBSD has shipped with the
appropriate timezone files for years; even though changes to timezones
in general and DST rules in particular happen a few times a year
throughout the world, the NetBSD operating system has of course always
provided accurate and up to date zone files as soon as possible.

The Energy Policy Act of 2005 was signed into USA law on August 8, 2005.
The updated tzdata package (tzdata2005m) was imported into our source tree
on August 29, 2005, and was pulled up into the netbsd-2 (September 5,
2005), netbsd-2-0 and netbsd-3 (both September 6, 2005) branches and is
thus present in NetBSD 2.0.3, 2.1, 3.0, 3.0.1, 3.1 and the 4.x branches.

In other words, if you’re running one of these systems, no action on your
part is required; your system is already prepared for the updated
timezones and will continue to show the correct local time.

If you are running an older system, we strongly encourage you to update to
one of these releases. However, we do recognize that some organizations
may have the need to continue to run older releases. You can update those
systems as follows:

# cd src
# cvs update share/zoneinfo
# make install

Per default, /etc/localtime is a symbolic link to the actual timezone file
under /usr/share/zoneinfo. However, if on your system / and /usr are not
on the same partition, you need to copy the zone file from
/usr/share/zoneinfo to /etc/localtime to make sure that services starting
before /usr is mounted get the correct time.

After installing the new zonefiles and making sure that /etc/localtime
points to the correct file, you need to restart any and all running
services that rely on the correct local time (such as crond, syslogd
etc.): /etc/localtime is only read once when the application starts up,
and any changes to that file are not picked up until the application is
restarted.

A reboot is not required, however, it is an easy way to make sure that all
services are restarted and pick up the new information.

http://www.boston.com/news/nation/articles/2007/03/04/a_new_daylight_is_dawning/

A surprising side-effect I’ve heard of is for businesses (e.g., clinics) that use date of birth to verify personal identity. A midnight hour is sometimes stored or defaulted for DOB, and if an application-wide date-correction routine isn’t carefully tailored it can adjust DOB for those with birthdates in the 4-week window from March - April to appear as one day early.

The daylight savings time switch to a March start is a major hassle for appointment scheduling systems.

Is it getting lighter out earlier than it use to? That’s my question. Does anyone have any information on this? Or, is there a website that explains it all?

Thank you!