Re: [sqlite] A question about the use of localtime
Matthew: I simply called tzset() after I extract the timezone file. It worked like a charm. Thank you very much! I was having a heck of a time information online. On Thu, Jun 19, 2008 at 4:53 PM, Matthew L. Creech <[EMAIL PROTECTED]> wrote: > On Thu, Jun 19, 2008 at 4:35 PM, Matthew L. Creech <[EMAIL PROTECTED]> wrote: >> >> 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. >> > > Correction - that's what happens when localtime_r() is called; > localtime() is guaranteed to call tzset() on each invocation. > > So one option here is to just disable use of localtime_r(), since > presumably the configure script detects it and defines > HAVE_LOCALTIME_R in config.h. > > -- > Matthew L. Creech > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] A question about the use of localtime
On Thu, Jun 19, 2008 at 4:35 PM, Matthew L. Creech <[EMAIL PROTECTED]> wrote: > > 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. > Correction - that's what happens when localtime_r() is called; localtime() is guaranteed to call tzset() on each invocation. So one option here is to just disable use of localtime_r(), since presumably the configure script detects it and defines HAVE_LOCALTIME_R in config.h. -- Matthew L. Creech ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] A question about the use of localtime
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
[sqlite] A question about the use of localtime
All:
I noticed the following when using sqlite to timestamp flags in an
embedded system. I will lay out the tests performed and the results I
got.
First, an overview. I am working with a linux 2.6.26 kernel and
sqlite v3.5.0. For the handling of timezones, I use the zoneinfo
files. /etc/localtime
is a symbolic link to /var/tmp/localtime. At boot the proper timezone
file is copied to /var/tmp/localtime (the reason for this setup is
/etc resides
in a read only partition. I timestamp each flag using 'Insert into
flags (timestamp, FLAGDATA...) values (datetime('now','localtime),
FLAGDATA)'.
Now on to my issue.
--Scenario A--
Boot System
Update /var/localtime with correct zoneinfo file
Write Flag(s)
--
Result All time stamps match my localtime.
--Scenario B--
Boot System
Write 1 Flag
Update /var/localtime with correct zoneinfo file
Write a few flags (5-10)
Some time elapses
Write some more flags
---
Result...
The first flag ,written before /var/localtime, is written in UTC. I
expect this since the symbolic link does not yet point to a valid
zoneinfo file.
The next few flags (5-10 depending on what the system is doing) are
also in UTC, these flags are the same flags written
in Scenario A after the zoneinfo update.
The system may briefly stop writing flags, then write some more due to
a button press or something.
Eventually the flags receive the correct timestamp for my timezone
settings. I think, but cant say for certain, that the
timestamp becomes 'correct' after a small amount of time elapses.
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.
My last bit of information which may be relevant is all flags are
written in individual transactions.
Thanks in advance,
Rich
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
