Re: [PATCH] initscripts: Properly handle new timestamp format

[Gary Thomas <gary@mlbassoc.com>]

On 2012-03-01 08:44, Richard Purdie wrote:
> On Thu, 2012-03-01 at 08:27 -0700, Gary Thomas wrote:
>> On 2012-03-01 08:11, Gary Thomas wrote:
>>> On 2012-03-01 07:59, Richard Purdie wrote:
>>>> On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote:
>>>>> Recent changes have attempted to make consistant use of /etc/timestamp
>>>>> In particular
>>>>> 5aab665 initscripts: Make /etc/timestamp consistent again.
>>>>> 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes
>>>>>
>>>>> This new format can cause problems as the value is too large for
>>>>> most [32 bit] machines. Work around this by only comparing the
>>>>> YYYYMMDD portion (which does fit in 32 bits). Also, the new format
>>>>> is not directly compatible with the 'date' command line, so it
>>>>> must be reformatted for use.
>>>>>
>>>>> Signed-off-by: Gary Thomas<gary@mlbassoc.com>
>>>>> ---
>>>>> .../initscripts/initscripts-1.0/bootmisc.sh | 4 ++--
>>>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> I merged the changes to busybox in relation to this. Is this patch still
>>>> needed?
>>>
>>> Let me check - I didn't see the related busybox change.
>>>
>>
>> I missed the busybox change because there was no PR bump :-(
>>
>> The problem with the change turning off CONFIG_FEATURE_DATE_COMPAT is that
>> now 'date' from busybox works one way and 'date' from coreutils works another.
>>
>> Using coreutils:
>>
>> root@cobra8148p81:~# date 201203011520
>> date: invalid date `201203011520'
>> root@cobra8148p81:~# date 030115202012
>> Thu Mar  1 15:20:00 UTC 2012
>> root@cobra8148p81:~# ls -l /bin/date
>> lrwxrwxrwx 1 root root 14 Mar  1 15:14 /bin/date ->  date.coreutils
>>
>> Using busybox:
>>
>> root@cobra8148p81:~# ln -s /bin/busybox /tmp/date
>> root@cobra8148p81:~# /tmp/date 201203011520
>> Thu Mar  1 15:20:00 UTC 2012
>>
>> I think the best thing would be to turn CONFIG_FEATURE_DATE_COMPAT back
>> on along with my reformatting change.
>>
>> I can make an updated patch if you agree.
>
> Is this going to cause us a problem in real world usage? I'd hope in the
> general case we use standard formatting?
>
> I have to admit I'm getting more than a little frustrated with what
> seems like a continual set of changes bouncing this format around in
> different directions :(.

I agree and I'm sorry I missed this in my first change - I was just
trying to make the time stamps be consistent.

As far as I can recall (which is a really long time), 'date' has always
wanted the format MMDDHHmm[YYYY], so I think that's what we should expect.
That format doesn't compare easily which is why the timestamp was changed
(not by me) to a more ISO standard YYYYMMDDHHmm.  If busybox has 64-bit
math enabled, then this can be compared with no problems, it just has
to be munged into the format 'date' wants.


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------