On 01/24/2017 06:10 PM, Rich Felker wrote: >>> 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.
According to man 2 time: time() returns the time as the number of seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC). I.E. the definition of unix time is UTC. So %s _not_ being UTC is silly. My use case (and presumably most people's) is turning a time string into a struct timespec. What the actual struct tm fields are is irrelevant to that as long as mktime() translates the result back to the right number. The struct tm has a timezone field in it. As long as strptime sets the timezone when it adjusts the hours so mktime() can adjust it _back_, the result is the same number you fed into %s. Which is the point of the exercise. (Remember when Linux systems used to have a "store system clock in GMT instead of localtime" option during config, and the config option went away because nobody ever _didn't_ do that? Yeah, that.) > Rich Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net