On Tue, Jan 24, 2017 at 05:47:46PM -0600, Rob Landley wrote: > > > On 01/21/2017 06:25 PM, Rich Felker wrote: > > On Sat, Jan 21, 2017 at 03:18:28PM -0600, Rob Landley wrote: > >>> Or if it's signed, that's -1346458162 which would be... sometime in the > >>> 1930's? hmmm... "./date -D %s -d -1346458162" is failing under glibc, > >>> and failing _differently_ under musl. (Wheee.) > >>> > >>> /me goes down tangent rathole debugging why. > >> .... > >>> > >>> (Answer: musl doesn't implement %s at all, and glibc doesn't allow the > >>> %s value it converts to be negative.) > >> > >> Query: does bionic strptime() handle %s, and if so does it handle > >> negative input values? (If not I suppose I can try to special case this > >> in toybox, but ew.) > >> > >> Also, Rich: any interest in adding this to musl? > > > > strptime with %s? I suspect there are some nasty underspecified issues > > with how it interacts with timezones. > > I thought unix time was always UTS and the timezone just affected how it > was displayed?
The problem is that strptime produces a struct tm. When the fields it's parsing to produce this struct tm are "broken down time" fields, strptime does not need to know/care whether the caller is going to interpret the struct tm as UTC or local time; it's just a bunch of numbers. But when strptime is going to take a unix time value (seconds since epoch) and convert it to struct tm, it matters whether the caller is supposed to treat that struct tm as UTC or local. Rich _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
