On 07/28/2015 03:51 PM, enh wrote: > (i don't care about this -- and didn't know it existed before today -- > but noticed it while fixing a bug i do care about, the patch for which > i've already sent you...) > > the toybox code seems to think -s lets you specify the format used > when setting a time.
The thing is, +FORMAT is only display format. It's for _output_, not for input. When you give date a string it has to parse as a date, the gnu/dammit date is hardwired to only accept certain magic input formats. (Well, it has a mostly undocumented "date -d @1234567890" that's hardwired to accept unix time in seconds, but I only learned about that recently. So my solution was general, and theirs was a special case to add one more specific hardwired format because gnu.) My first attempt was applying +FORMAT to input in certain circumstances, because if you do: date +%s -d 1234567890 The behavior you should get seems obvious, although gnu gives you an error message instead. Unfortunately that didn't cut it because if you want to convert a date from one format to another, and display the result rather than setting the system clock, you have to specify the input format _and_ the output format separately at the same time. So I needed a "format for input" option. (-s not only isn't posix, it's what's mandated to happen if you give posix an extra argument.) (I think I was messing around with mbox conversion and hitting times specified in multiple formats that needed to be regularized and compared? I needed a tool to do that from the command line, and there just wasn't one.) > that doesn't seem to match the coreutils behavior. No it doesn't. (Sigh. I had long discussions with somebody about this, but I think it was in 2013 when I was up in Minnesota, and I'm not finding it in my blog or the mailing list archive. Most likely it was on irc?) When Walter Harms added this feature to busybox a decade ago, he used -D for it: http://git.busybox.net/busybox/commit/coreutils/date.c?id=c5789a6e234c1ddec204cf65f319babb04ca6a47 I can change from -s to something else and add the completely useless -s meaning back if you like? For people who actively hate posix... > experiment suggests that -s takes an argument similar to > -d/--date, which is described thus on the man page: Bad sign you had to experiment. Toybox --help says: -s +FORMAT for SET or -d (instead of MMDDhhmm[[CC]YY][.ss]) The SET referred to there is the one from the usage: line. Alas it's hard to be simultaneously terse, obvious, and thorough when explaining stuff. Looks like I need to make another stab at it? I wanted to be able to convert an arbitrary date format _to_ another arbitrary date format, and couldn't figure out how to beat that behavior out of posix or gnu. I didn't start from the gnu implementation here, I started from posix's date spec, which has one of the more horribly written command descriptions: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html I.E. you'll never tell from their usage line, but the last argument is optional. If it's not there, display time. If it is there, set time. You can have a +FORMAT argument that explicitly controls _output_ format, but not input format. I tested several variants of beating this behavior out of gnu date, and even went so far as to install the "info" command to look at that documentation since they keep _not_ documenting stuff in their man pages and nobody ever bothers to put info pages online because nobody outside of gnu cares about them. I'm pretty sure the @date thing was added since I dug (possibly in response to me asking people about it, wouldn't be the first time). > DATE STRING > The --date=STRING is a mostly free format human readable date string > such as "Sun, 29 Feb 2004 16:21:42 -0800" or "2004-02-29 16:21:42" or > even "next Thursday". A date string may contain items indicating cal‐ > endar date, time of day, time zone, day of week, relative time, rela‐ > tive date, and numbers. An empty string indicates the beginning of the > day. The date string format is more complex than is easily documented > here but is fully described in the info documentation. > Hence why I installed the info documentation. How do you parse a free format human readable date string? Busybox had 4 random ones it tried in order with no explanation of where they came from. I vaguely recall the gnu/dammit version would go open some random file where you could list formats in your order of preference. Me, I went "let the user specify this" instead of magic heuristics. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
