From jabley@mfnx.net  Thu May 31 08:46:30 2001
Return-Path: <jabley@mfnx.net>
Received: from box.mfnx.net (box.mfnx.net [64.124.216.37])
	by hub.freebsd.org (Postfix) with ESMTP id B752637B422
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 31 May 2001 08:46:30 -0700 (PDT)
	(envelope-from jabley@mfnx.net)
Received: (from jabley@localhost) 
	by box.mfnx.net (8.9.3/8.9.1) id IAA22666; Thu, 31 May 2001 08:46:30 -0700 (PDT)
	env-from (jabley@mfnx.net)
Message-Id: <200105311546.IAA22666@box.mfnx.net>
Date: Thu, 31 May 2001 08:46:30 -0700 (PDT)
From: jabley@mfnx.net
Reply-To: jabley@mfnx.net
To: FreeBSD-gnats-submit@freebsd.org
Subject: Use of -v flag of date(1) can give non-intuitive results
X-Send-Pr-Version: 3.2

>Number:         27796
>Category:       bin
>Synopsis:       Use of -v flag of date(1) can give non-intuitive results
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    brian
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu May 31 08:50:01 PDT 2001
>Closed-Date:    Mon Jul 30 11:42:12 PDT 2001
>Last-Modified:  Mon Jul 30 11:43:08 PDT 2001
>Originator:     Joe Abley
>Release:        FreeBSD 3.4-RELEASE i386
>Organization:
Metromedia Fiber Network
>Environment:

Tested on FreeBSD 3.4-RELEASE and also  4.3-STABLE #1

>Description:

  jabley@goose[132]$ date         
  Thu May 31 11:44:23 EDT 2001
  jabley@goose[133]$ date -v+1m
  Sun Jul  1 11:44:25 EDT 2001
  jabley@goose[134]$ date -v+1m +%m
  jabley@goose[136]$ date -v+1m +%m
  07

Intuitively, I would expect "date -v+1m +%m" to mean "tell me
the number of next month", and return 06 instead of 07.

Looking at the source to date(1), it looks as though -v+1m just adds 
1 to the tm_mon element of the struct tm (see src/bin/date/vary.c).
The problem then is that the resulting date is 31 June 2001, and since
June only has 30 days, the month gets wrapped.

As the manual page says:

             When the date is adjusted to a specific value that doesn't actu-
             ally exist (for example March 26, 1:30 BST 2000 in the
             Europe/London timezone), the date will be silently adjusted for-
             wards in units of one hour until it reaches a valid time.  When
             the date is adjusted to a specific value that occurs twice (for
             example October 29, 1:30 2000), the resulting timezone will be
             set so that the date matches the earlier of the two times.

It doesn't say so explicitly, but I suspect similar logic is being
applied to days that don't exist within a month.

>How-To-Repeat:

  jabley@goose[132]$ date
  Thu May 31 11:44:23 EDT 2001
  jabley@goose[133]$ date -v+1m
  Sun Jul  1 11:44:25 EDT 2001
  jabley@goose[134]$ date -v+1m +%m
  jabley@goose[136]$ date -v+1m +%m
  07

Run on any day N of month M where month (M+1) has less than N days.

>Fix:
	
None suggested -- I'm not sure if my semantic understanding of the
-v flag is accurate.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: brian 
State-Changed-When: Thu May 31 16:28:17 PDT 2001 
State-Changed-Why:  
Adjusting the date is not as straight forward as some might think.   
To find out what ``next month'' is you should ``date -v1d -v+1m +%m''  
as there is always a ``day 1'' in each month. 

Your example is avoided in the man page as this rounding is done by  
mktime(3).  Another good (confusing) example is  
``date -v3m -v29d -v-1m''. 

If you (or anyone) care to produce documentation patches, I'm certainly  
happy to see if I can get them past a freebsd-doc review :) 


Responsible-Changed-From-To: freebsd-bugs->brian 
Responsible-Changed-By: brian 
Responsible-Changed-When: Thu May 31 16:28:17 PDT 2001 
Responsible-Changed-Why:  
date -v is my fault^w^wmine 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27796 
State-Changed-From-To: feedback->closed 
State-Changed-By: brian 
State-Changed-When: Mon Jul 30 11:42:12 PDT 2001 
State-Changed-Why:  
No response from the submitter 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27796 
>Unformatted:
