[haiku-3rdparty-dev] Re: Fetching data from queries
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-3rdparty-dev@xxxxxxxxxxxxx
- Date: Thu, 05 Nov 2009 16:51:04 +0100
-------- Original-Nachricht --------
> Datum: Thu, 05 Nov 2009 16:25:26 +0100
> Von: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
> "Ingo Weinhold" <ingo_weinhold@xxxxxx> wrote:
> > > "Ingo Weinhold" <ingo_weinhold@xxxxxx> wrote:
> > > > I just tried it myself under Haiku and there seems to be an issue
> > > > with the time zone not being considered correctly (in GMT+1 I
> > > > have
> > > > to specify "%+50 mins%" to get the files modified at most ten
> > > > minutes ago).
> [...]
> > > Maybe parsedate() is to blame for this. The BFS time stuff
> > > currently
> > > doesn't care about timezones, which you could also call a bug,
> > > though.
> > parsedate() gets the current time as a parameter, so for relative
> > time
> > strings, it can hardly do anything wrong. BQuery passes time(NULL) to
> > it,
> > which should be the local time.
>
> AFAIK time(NULL) returns the system time, which is probably UTC on your
> system?
Indeed it is.
> > It's really the question what time should be passed to the kernel
> > (local or
> > UTC) and how BFS handles it.
>
> BFS just don't care right now, but I think it would make sense to always
> use UTC as a time base there.
Or rather the hardware time -- otherwise the kernel would need to be able to do
timezone conversions. I guess this makes sense, given that the stat structure
also seems to contain hardware time values.
> Currently, BFS uses real_time_clock_usecs() which should be equivalent
> to time(NULL) besides the higher resolution.
That raises the question where the one hour offset comes from on my machine,
though.
CU, Ingo
Other related posts:
