[Toybox] [PATCH] Fix several bugs in date.

[Rob Landley]

On 08/14/2015 11:55 PM, enh wrote:
> On Tue, Aug 11, 2015 at 2:09 PM, Rob Landley <rob at landley.net> wrote:
>> On 08/11/2015 02:10 PM, enh wrote:
>>> On Mon, Aug 10, 2015 at 11:58 PM, Rob Landley <rob at landley.net> wrote:
>>>> On 08/10/2015 10:39 PM, enh wrote:
>>>>> Fix several bugs in date.
>>>>
>>>> Sigh. I honestly did test it, although clearly not thoroughly enough.
>>>> (That's how I set my clock to the year 2157, which networkmangler did
>>>> _not_ like...)
>>>
>>> yeah, that's the advantage of having real unit tests. -d lets us test
>>> the parsing reasonably well though (even if toybox's -d is
>>> incompatible with coreutils').
>>
>> If you mean "doesn't support multiple different fallback formats via
>> some magic /etc file they only tell you about in the info pages", yes.
>> If you mean something else, tell me more and maybe I can fix it?
> 
> no, i think toybox is saner than GNU here. i was just obliquely
> pointing out that these tests will fail when run against the host
> tools.

I've never quite been sure how to handle those cases. I have two
SKIP_HOST=1 tests in sed.test but should probably make it _say_ SKIP:
for the status.

(At some point, the test suite needs about as much work as the shell.)

>> I admit that "date -D %s -d 1234567890 +%s" isn't something gnu date
>> supports, although it can do date -d @1234567890 %s
> 
> yeah, it's the "date -d 14081805" format that toybox supports (yay!)
> but GNU doesn't (boo!).

Posix is pretty explicit about that century _and_ year are optional:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html

mmddhhmm[[cc]yy]

cc is the century and is the first two digits of the year (this is
optional); yy is the last two digits of the year and is optional. If
century is not specified, then values in the range [69,99] shall refer
to years 1969 to 1999 inclusive, and values in the range [00,68] shall
refer to years 2000 to 2068 inclusive. The current year is the default
if yy is omitted. [Option End]

That said, I documented a deviance from posix:

 * Note: setting a 2 year date is 50 years back/forward from today,
 * not posix's hardwired magic dates.

Because the same magic date range is in the 1997 spec as in the 2013
update of the 2008 spec:

http://pubs.opengroup.org/onlinepubs/7908799/xcu/date.html

I.E. once again posix is stuck in the 90's, which ended 15 years ago now.

>> Oh, side note: cpio doesn't store xattrs. It also has a 32 bit date
>> (y2038) and 32 bit file lengths. This means initramfs is kinda limited.
>> Do you care strongly about this?
> 
> the ramdisk is on its way out. i think some of this work is already
> visible in AOSP. there are certainly people internally running devices
> that boot from a squashfs system image and although they do still have
> a ramdisk, they only use it for the recovery image. (with the longer
> term plan killing that too.) so "no, i don't think so".

Except initramfs isn't a ramdisk, it's a dynamically resizing tmpfs
instance populated by extracting an archive into it, and that archive
can be part of the kernel image so you can boot a kernel without any
external root filesystem.

I wrote documentation about this long ago:
https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt

And then a couple years back I did:
https://lwn.net/Articles/559176/

*shrug* Android not using it is fine, but the main reason "ramdisk" is
obsolete is because "ramfs" replaced it, and they're really not the same
thing.

Rob

 1439614026.0