[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: BUILDTIME: ISO 8601 format [PATCH]
From:       Rob Landley <rob () landley ! net>
Date:       2005-11-29 22:02:16
Message-ID: 200511291602.16693.rob () landley ! net
[Download RAW message or body]

On Tuesday 29 November 2005 15:23, Ralph Siemsen wrote:
> My prediction: if the change is made, most folks will not notice, but
> the odd manufacturing script will break, because its regex for
> collecting the date will need to be fixed.  This is a pretty easy fix,
> but the guy in charge of manufacturing will not know anything about
> regex, and will therefore just label system as "buggy all of a sudden".

If it coincides with the change from 1.0 to 1.1, I'm really not put off by 
this. :)

>   Many months later, word might eventually make it back to this mailing
> list, and someone will ask why the format was changed.  Of course, by
> that time we'll say "it has been that way for months, why did you not
> complain earlier".

I just got Shaun's new patch, and I really don't see the benefit.  They're 
both human readable (the existing format slightly more so), and it seems that 
the only real use for this thing is making sure that the version you built 
and the version you installed match.  Nobody's come up with an example of 
tool that could parse the new format but not the existing one, and as far as 
I can tell it could be completely arbitrary as long as it's unique, modulo 
programmers eyeballing it.

The current thing is a string of numbers and punctuation.  Yeah, there are 
probably internationalization issues, but not important ones.  I can make the 
punctuation go away by printing out seconds since the epoch, but A) "%s" is a 
gnu extension we apparently don't support yet, B) it's slightly less human 
readable than what's there, C) I don't care.  (Looking at other date options, 
date -u is just another way of saying TZ=UTC, and RFC822 format (date -R) has 
far more internationalization problems than what we've got, plus it wouldn't 
sort, plus it's gratuitous change.)

> Anyhow, I think its pretty clear that I'm alone in my little "T is ugly"
> campaign, so I'll withdraw my comments.

Oh I agree it's ugly.  But that only enters into it if there is no functional 
difference, which hadn't been established.

> Have at your ISO, RFC, TLA  methodologies.  I'll just stick with "if it
> ain't broke don't fix it". 

I'm leaning towards that too.

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]