On 2/13/19 6:11 AM, Rob Landley wrote: >> Fix some comments now Rob's pointed out that the "weird" format was just >> POSIX with implicit CCYY or CC. (I was confused because coreutils rejects >> them [as it rejects all POSIX input to -d], but busybox does accept them, >> but interprets them differently, as explained in the test comments.) > > Hmmm... busybox is probably right that it should use the current year.
Which raises the question of whether the struct tm should be intialized to localtime() instead of memset to zero, but the _problem_ is that +FORMAT is for the output format, not how to parse --date. In fact there's no gnu/dammit way to specify a format to parse --date that I've ever found (it just pachinkoes over the heuristics). An original busybox extension (-D) was added on my watch back in he day: http://lists.busybox.net/pipermail/busybox/2006-February/018203.html But the gnu/dammit guys never copied it because Not Invented Here I suppose. And Jorg Schilling's not dead yet so I haven't submitted it to Posix, and it's not like they'd ever notice on their own... So figuring out what the _correct_ behavior is here is uncharted territory. But I _suspect_ it's "initialize fields with current time, then write supplied fields over them"? If you want a cannonical way to record an instant in time, it's unixtime (with fractional part). For all the rest of it, "January 3rd" generally means this year. "The third" means this month... Seem reasonable? Rob PS. I can understand having localtime() and gmtime() pay attention to an environment variable for historical reasons, but when you make an _r version and DON'T pass the timezone as an argument what is WRONG with you? Answer: the FSF is what's wrong with you... Grrr, funky side channel signaling via global state... _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
