[Toybox] [PATCH] Support the %N coreutils/busybox extension to date.

[enh]

On Sun, Apr 16, 2017 at 1:28 PM, Rob Landley <rob at landley.net> wrote:

> On 04/15/2017 01:17 PM, enh wrote:
> >
> > Used by the toybox touch test suite (and thus necessary to pass the
> toybox
> > tests on a toybox-only system).
>
> Did I ever actually post my rant on this topic? Or just compose it and
> save as draft.
>
> This is really really libc's job, it's a pity the gnu guys didn't
> coordinate with the glibc developers. (On the other hand, I suppose
> that's why glibc wasn't worse.)
>

yeah, definitely a mess.

note that i only did this because (a) existing tests were using it and (b)
busybox has it too. i've been assuming (perhaps incorrectly) that busybox
also tried to avoid needlessly implementing GNU extensions unless they were
actually useful to enough people.


> Yes "struct tm" doesn't have nanoseconds, and they don't want to make it
> bigger because binary compatibility. But lp64 says int is 32 bits, so
> they could stick the nanoseconds in the middle 30 bits of tm_isdst (old
> 0 and 1 inputs only flip the bottom bit, -1 sets the top bit, middle 30
> bits are basically unused and can store 0-999999999; old code that sets
> the field to -1 means nanoseconds are over 999999999 and you can treat
> that as 0). Then strptime and strftime could both have access to
> nanoseconds and could both implement %N. It's a little awkward but more
> or less backwards compatible.
>
> I already have date.c accepting nanoseconds input in its
> @unixtime.fraction format. I pondered doing it for the
> MMDDhhmm[[CC]YY][.ss] one but it doesn't OUTPUT that format which is
> just sad. (Be symmetrical, people!) I've pondered _adding_ a flag to
> make date output that, but "toybox tests require toybox commands" is a
> bridge I haven't crossed yet.
>
> Speaking of which, this patch adds %N to output but not to input, so
> date can still only _set_ nanoseconds using the @123456789.123456789
> syntax.


isn't setting via arbitrary format a toybox extension?


> And you're not checking that "%%N is a literal %N". (Sigh. If
> we're going there, may I draw your attention to next_printf() in
> lib/lib.c? Example usage in seq and stat.)
>

okay, i'll switch it over (assuming we actually want %N).


> It's kind of sad "ls" can't show nanoseconds. Or "stat". I understand
> why (nanoseconds were added when makefile dependencies started breaking
> as computers got faster and multiple build things happened in the same
> second; nothing else actually _needed_ them in the filesystem) but it's
> still half-assed.
>

~$ ls -ld --time-style=full-iso /
drwxr-xr-x 25 root root 4096 2017-04-10 08:08:16.298419414 -0700 /
~$ stat /
  File: ‘/’
  Size: 4096       Blocks: 8          IO Block: 4096   directory
Device: fc01h/64513d Inode: 2           Links: 25
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-04-16 13:35:50.436148625 -0700
Modify: 2017-04-10 08:08:16.298419414 -0700
Change: 2017-04-10 08:08:16.298419414 -0700
 Birth: -
~$

i'm happy to rewrite the tests instead... i've never used %N personally,
and would just naturally use stat for this kind of thing.

as you say, the asymmetry is ugly, and the divergence from libc is ugly, so
if busybox added this "just because" maybe we shouldn't have it at all?


> Grumble grumble...
>
> Rob
>



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20170416/a5c2a811/attachment-0003.htm>