On 2/13/19 11:18 AM, enh wrote: >> 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? > > mostly. personally i think unix and ISO are both reasonable, but that > in general any format that elides _larger_ stuff than you've already > given should just be rejected (and eliding anything _smaller_ gets you > zeros). so folks saying 2019-02-13 getting the other fields zeroed > sgtm, but i'd just say "no" to 02-13 or equivalents. i'm maybe > sympathetic to accepting "09:15" meaning "just leave the date alone", > but honestly think even that will probably cause more harm over its > lifetime than the good it will do.
Which means your array of accepted formats needs a "to blank nor not to blank" field, which could just be an initial ! character or something. P.S. 0x2b|!0x2b==0xff > (i was pleased to see that the AOSP build only uses unix and ISO. and > of course we're obliged to support POSIX, even if it does have the > weird [[CC]YY] behavior. and is little-endian.) But the build uses the TZ stuff? >> 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... > > the BSDs have _tz variants, but iirc they're subtly different because > that's what BSD does best. I continue to plead the third. (Why are we calling tzset() again? What's the point?) Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
