bugfindutils - Bugs: bug #22662, Nanoseconds field occurs in the...

 
 

bug #22662: Nanoseconds field occurs in the wrong position for some time formats

Submitted by:  None
Submitted on:  Tue 18 Mar 2008 07:19:35 PM UTC  
 
Category: findSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: James Youngman <jay>
Originator Name: blazOriginator Email: -unavailable-
Open/Closed: ClosedRelease: 4.4.0
Fixed Release: 4.5.1

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 31 Aug 2008 02:23:15 PM UTC, comment #5:

Fixed in 4.5.x.

James Youngman <jay>
Project AdministratorIn charge of this item.
Sat 21 Jun 2008 12:46:34 PM UTC, comment #4:

I've sent this patch to -unavailable- for review.

(file #15902)

James Youngman <jay>
Project AdministratorIn charge of this item.
Fri 16 May 2008 10:40:40 PM UTC, comment #3:

I believe that the attached patch fixes the problem.

(file #15671)

James Youngman <jay>
Project AdministratorIn charge of this item.
Fri 21 Mar 2008 03:29:17 PM UTC, comment #2:

My previous comment didn't address the "find -printf" formats %a, %c, %t, which also currently contain a fractional part in the seconds field; I am not proposing to change those.

James Youngman <jay>
Project AdministratorIn charge of this item.
Fri 21 Mar 2008 03:24:09 PM UTC, comment #1:

Yes, the %AX problem is indeed a bug, and thanks for letting us know about it.

%AX uses the strftime format %X. That yields the locale's preferred time representation:-

$ for locale in POSIX fr_FR.UTF-8 en_IE.UTF-8 en_US.UTF-8; do printf "%-13s [%s]\n" "$locale" "$(LC_ALL=$locale date +%X)"; done
POSIX [14:31:09]
fr_FR.UTF-8 [14:31:09]
en_IE.UTF-8 [14:31:09]
en_US.UTF-8 [02:31:09 PM]

It looks like the en_US.UTF-8 locale uses the %r format for strftime's %X format. POSIX allows us to determine what format is being used by calling nl_langinfo():

$ LC_ALL=en_US.UTF-8 ./locale_time_formats
POSIX locale:
D_T_FMT : [%a %b %e %H:%M:%S %Y]
D_FMT : [%m/%d/%y]
T_FMT : [%H:%M:%S]
en_US.UTF-8 locale:
D_T_FMT : [%a %d %b %Y %r %Z]
D_FMT : [%m/%d/%Y]
T_FMT : [%r]

On the other hand my locale has T_FMT=%T. It should be safe to append nanoseconds for formats where T_FMT yields just %S (won't happen), %T, or %s (also won't happen), or where the format ends in %S.

If we know the locale is POSIX, we could manually translate %r to
%I:%M:%S %p so that the %S expands correctly, and we can probably do that in all cases for %T.

However, there is another likely bug in the implementation. It hard-codes the use of "." as the radix character instead of using the value of RADIXCHAR.

However, these things would be hard to document. How about doing things this way:

1. In the POSIX locale, the seconds field always includes a fractional part, for all formats.

2. In locales other than POSIX, the only fields for which find will include nanoseconds are %[ACT]S, %[ACT}+, %[ACT]@ and %[ACT]T, and in those cases the locale's radix character will separate the whole part and the fractional part. In locales where the strftime formats %X and %T are identical, this will also happen for %[ACT]X. (Here, "%[ACT]X" means "%AX, %CX or %TX").

3. In other cases the seconds field may lack a fractional part.

In terms of what will change with respect to 4.4.0:
a) No change in the POSIX locale
b) Change in behaviour of %AX, %CX, %TX for non-POSIX locales.
c) Use of radix character where appropriate, versus "." previously.

The upside of this approach is that it is relatively easy to document and the behavioural change is small.

A down-side is that it makes it hard for scripts to consume the output of %[ACT]X. On the other hand, that output is already hard to consume since it has a bug in the 4.4.0 release, and in any case it is probably better to specify "%AT %Ap" if that is what you actually want, rather than "%AX".

James Youngman <jay>
Project AdministratorIn charge of this item.
Tue 18 Mar 2008 07:19:35 PM UTC, original submission:

I'm actually using find version 4.4.0, unfortunately it is not yet available in drop down box, so I selected version 4.3.9.

Since version 4.2 you have changed behaviour of format specifiers for time. For some (@, S, +) this change is clearly documented in man and info pages. But for others (T, X) this change is not documented.

Since output of %AX looks strange (08:12:22 PM.0056544350) I'm also wondering if this is a bug in code and not just incomplete documentation.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jay (Updated the item)
  • -unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 31 Aug 2008 02:23:15 PM UTCjayStatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
      Fixed ReleaseNone=>4.5.1
    Sat 21 Jun 2008 12:46:34 PM UTCjayAttached File-=>Added 0001-Fix-Savannah-bug-22662-wrong-result-of-AX-format.patch, #15902
      StatusNone=>In Progress
    Sat 21 Jun 2008 12:35:29 PM UTCjaySummaryincomplete documentation for sub-second time stamps in find -printf format specifiers=>Nanoseconds field occurs in the wrong position for some time formats
    Fri 16 May 2008 10:40:40 PM UTCjayAttached File-=>Added 0001-Fix-Savannah-bug-22662-nanoseconds-appended-after.patch, #15671
    Wed 19 Mar 2008 08:40:39 PM UTCjayAssigned toNone=>jay
      Release4.3.9=>4.4.0

    Back to the top


    Powered by Savane 3.1-cleanup1