On Wed, Feb 13, 2019 at 10:14 AM Rob Landley <[email protected]> wrote: > > 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.
or we remove the last two entries, which i have no use for and probably shouldn't have added (but they're in `busybox date --help` and not obviously terrible, other than this issue) :-) > 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? yes. specifically for stuff like `TZ="UTC" 2019-02-13`. > >> 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?) hysterical raisins^W^Whistorical reasons. afaik, you don't need that on any *current* OS. but historically that line in the (localtime docs)[http://pubs.opengroup.org/onlinepubs/9699919799/functions/localtime.html] about "as though localtime() calls tzset()" wasn't there, so to be safe you call tzset(3) manually. i don't remember exactly when Android and iOS fixed this, but i'm pretty sure it was in the last 7 years. (and i do remember that we fixed it because someone had code that relied on it and it was working everywhere else at that point.) but since _i_ only care about current Android (and you probably only care about old Android with a static libc anyway, because good luck trying to get toybox to build on old Android), i think we can rip all the tzset()s out. > Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
