Date: Wed, 16 May 2001 03:05:24 +0200 From: Erik Trulsson <ertr1013@student.uu.se> To: Crist Clark <crist.clark@globalstar.com> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: mktime(3) Bug? Message-ID: <20010516030524.A56457@student.uu.se> In-Reply-To: <3B01CD18.6E725786@globalstar.com>; from crist.clark@globalstar.com on Tue, May 15, 2001 at 05:43:04PM -0700 References: <3B01CD18.6E725786@globalstar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 15, 2001 at 05:43:04PM -0700, Crist Clark wrote: > Before I send in a PR, I wanted to make sure this was really a bug and > not some bizarre "feature" everyone already knew about but me. > > I noticed odd behavior when doing some conversions with date(1) (FreeBSD's > date(1) rewls for letting you do these kinds of conversions, BTW). Note what > happens when I cross a daylight savings time boundary (which was the 1st > of April for my timezone this year), > > $ date > Tue May 15 17:11:52 PDT 2001 > $ date -j -f %Y%m%d%H%M 200104020000 > Mon Apr 2 00:00:41 PDT 2001 > $ date -j -f %Y%m%d%H%M 200104010000 > Sat Mar 31 23:00:46 PST 2001 > > At first I thought it might be a conversion-only problem, but you get > the same thing if you _set_ the time across a DST boundary. Looking at > the date(1) code and reviewing the manpages, my best guess is that > mktime(3) uses the _current_ DST settings when setting the "target" > time. > > That would explain the behavior. And that, IMHO, is a bug. When a > user types that second command, he expects to see midnight on the > 1st, not 11 PM on the 31st. The DST of the "target" time should be > used by mktime(3), not the current one. This is especially true if > the user were setting the time rather than just displaying it. > > This is a bug, right? I don't think it is a bug. The date/time you give to date(1) is interpreted as being in your local timezone. What your second example shows is that 2001-04-01 00:00 PDT is the same time as 2001-03-31 23:00 PST which I believe is correct. It is not so much DST setting but *timezone* setting that matters. According to the manpage mktime(3) uses the *current* timezone when interpreting a date. It appears as if date(1) also interprets the date that way. If it is a bug it is at least buggy in a consistent, documented manner :-) One might argue about what is the best way to behave but I am fairly certain that date(1) is designed to behave as it does. (And I wouldn't be surprised if some standard mandates this behaviour.) -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010516030524.A56457>