I didn't know this would end up so complicated :) Thanks Rob and I just tried it. It works for my use case and now understands the "stat" output for the date format.
Frank On Fri, May 28, 2021 at 4:07 AM Rob Landley <r...@landley.net> wrote: > On 5/28/21 4:06 AM, Rob Landley wrote: > > On 5/26/21 11:17 AM, Frank Liu wrote: > >> A bit background, the TZ string actually came from the "stat": > > > > I'm fine with it, I've seen that in mbox files and so on too. > > > > The question I have is how I feed the information to the libc functions. > Since > > setting TZ to "+1234" didn't work (nor did setting it to just 1234), I'm > > guessing I need to parse the data and assign it to "timezone" myself? > Except > > doing so appears to be ignored in glibc. From a quick glace at the musl > source > > it looks like it might work there? > > Ok, I need to feed libc TZ="UTC+xxxx" with no space, and THEN it > understands the > file format in the man page. > > Except if the date is "1980-01-02" and I peel off the trailing -02 as a > timezone > adjustment, it breaks. So I need to parse a comprehensible date format and > THEN > peel off time zone adjustments if there's anything left over. Which means > this > can't be in the parse_date() wrapper along with the TZ="" logic, this > needs to > go into xparsedate(), and... > > It's already in there. Sigh. Except for the part where it doesn't actually > work... because it doesn't understand the space. And it also can't handle > +01 or > "... + 01 : 01 " which is 5 spaces that the gnu/dammit one can so SOMEBODY > out > there is likely to have. > > Did you know that trailing + or - by themselves are ignored? They don't > count as > +0, the timezone is unchanged by them. Because GNU, of course. > > Alright, I checked something in. Try now? > > Rob >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net