On Thu, Jun 19, 2008 at 3:28 PM, Rich Rattanni <[EMAIL PROTECTED]> wrote: > > So this email isn't blaming SQLite for my improper timestamps even > after I set the correct zoneinfo file. I am just trying to > understand what is going on. Should I assume that my observation of > 'Set zoneinfo first, then use datetime functions' is > a valid fix? Or am I fooling myself? > I just wanted to know the mechanism at work here. Of course I do > fully acknowledge this is could be an artifact in the > GLIBC library. If someone knows the particular reason this is > happening, even if it is GLIBC fault, I would love to know. >
I think this behavior is probably due to the way localtime() works in glibc. From what I've seen (at least on my embedded ARM-Linux board), localtime() only invokes tzset() the first time it's run by an application. So if your app starts and calls localtime() before the timezone is changed, you'll get times formatted according to the old timezone. Our solution was to simply call tzset() before calling localtime(), since it wasn't in any sort of critical path. That's probably not a good solution in SQLite, but as a start, you may want to try calling tzset() yourself before each time you modify the flags, and see if that fixes the problem. -- Matthew L. Creech _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
