<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - return dates in UTC format" href="https://bugs.freedesktop.org/show_bug.cgi?id=94173#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - return dates in UTC format" href="https://bugs.freedesktop.org/show_bug.cgi?id=94173">bug 94173</a> from <a class="email" href="mailto:jakubkucharski97@gmail.com" title="Jakub Kucharski <jakubkucharski97@gmail.com>"> Jakub Kucharski</a> <pre>(In reply to Albert Astals Cid from <a href="show_bug.cgi?id=94173#c11">comment #11</a>) > Also are you guys sure returning the time in UTC is the right thing instead > of returnin time+timezone information? It's what time_t is supposed to hold. When someone uses a frontend which returns the date as time_t (cpp & glib), they will expect it to be UTC. Then they may call localtime and the returned struct tm will be wrong, because the time_t is wrong. Same goes for gmtime, where they'd expect UTC, but get local time. So that's for the part with time_t/mktime. My patch also takes the timezone info stored in the PDF into consideration. Poppler didn't use to do it, which could cause weird behavior, if someone saved a document in let's say UTC-6, sent it to a friend in a different timezone and they'd find out that the only difference in metadata dates they see comes from a bug concerning time_t/mktime. For more information we would need an internal datetime struct which we would pass on to the frontends where it would be converted to QDateTime, GDateTime and I don't know what for cpp (because cpp/boost is such a wonderful way of writing C++...). It would break the API though, so I don't know if it's the best idea. Anyway, time_t is spartan by design. It isn't of much use when one wants to store timezone info.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>