On 2017-07-24 15:48, Eric Blake wrote: > On 07/24/2017 04:28 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: >>> then its use of %s in either of those functions constitutes a _bug_ >> >> Oh really? Is that why "%s" was added to Cygwin's strftime() lately? > > Your mailer is breaking up threads, which is making it very annoying to > follow where your replies are landing. > > strftime() has been formatting %s since Oct 2015 (if you can call that > "lately"). In fact, you made me check git history: it was not me that > added it (like I thought, so I must have added it in gnulib instead); > but Brian - in fact, the same Brian who is now working on adding %s to > strptime(). > > The point remains: if you want your program to be portable, you should > not use %s. But if your program is okay with demanding a GNU/Linux > environment rather than sticking to portable code, then Cygwin still > tries to cater to that by providing as many GNU/Linux extensions as > possible, and pointing out where we fall short is appreciated. But > still, someone has to code it, this is a volunteer effort, and we tend > to scratch our own itches. The fact that strptime() lagged strftime() > by nearly 2 years in adding %s support is par for the course. It's not > worth complaining about, and if you want faster action, then submit > patches yourself instead of asking others to do it for you.
My itch is that it doesn't work in dateutils strptime(1), so the hope is that if %s (also %F) works in newlib libc strptime(3), that will get it working in dateutils strptime(1), as it does in coreutils date(1), or I'll have to do some more scratching. Of course, C code could just convert the seconds strings to some BIG_INT, put it in a time_t, and use localtime(3) or gmtime(3) to get a struct tm for use in strftime(3). Shell scripts could use coreutils date(1) instead of dateutils strptime(1) to convert time_t using %s (and more). It would be great if all the time utilities and functions could support a consistent set (GNU) of time conversion specifications. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple