Hi

> It is not Jaybird, but Java. Jaybird uses calendar to extract components

of the date. In your case Java returns 2009, 10, 25, 2, 59, 59 for the first
timestamp and 2009, 10, 25, 2, 0, 0 for the second. Jaybird simply encodes
that time.

That's what I think is wrong. Jaybird is just not computing the number of
seconds since the daystart!
I think it would be more correct to create another date object (same day,
00:00) and take the difference between those...

> Again, it's up to Java - driver will just extract components and set using

the system's default calendar.

That's why it simply does not make any sense to set Date or Calendar fields
without proper timezone first.

> The test case is not quite correct - it does not involve database which

also interprets timestamp according to the system locale...

Right, such a testcase would be more complex and propably even more
problematic.
However the code given shows that jaybirds internal encoding and decoding
functions are not even bijective! Neither are they inverted functions of
each other.

> Try to construct a case that involves database-side conversion of the

timestamp to string and then client side conversion from string back, you
would have a lot of fun.

That's why getDate() and getTimestamp() are there instead of getString() and
parsing... Good code should not parse anything that is already in a
computerreadable form, that's why I was very happy when I learned ealier
today, that timestamps are not sent to the client as strings but encoded
into those 8 bytes.

> And it is also not correct to say that Jaybird is playing tricks here -

that is Java, that does this conversion trick.

> See the following code...
> You will see the same formatted date (it uses default calendar, which now

is CET), but different number of milliseconds since "day zero".

No.
On my computer this code prints:

Time Sun Oct 25 02:30:00 CET 2009 is 1256434200051
Time Sun Oct 25 03:30:00 CET 2009 is 1256437800176

Which seems quite correct. Note the 02 vs 03 in the middle.

> Topic is complex and I suspect that we will not reach any agreement here -

there's too much room for interpretations and I know no specification that
would tell us how to use it.

I thought the specification would be, that the second encoded integer is the
number of seconds into the day...?
So this could be a good start.


I know, that this interpretation is also far from perfect. However it does
allow to store and read information exactly. As long as the timezone is not
changed inbetween, it would ensure that every timestamp written can be read
agan, which is not the case right now.

Currently I am thinking that this will render all time information on my
servers useless. If I cannot write a specific information and be sure, I can
get THAT information back, I might think about switing all timestamps from
real database TIMESTAMPS to INT64 and store milliseconds since xyz. I really
don't like that idea, as I always prefer database native types (especially
as it allows manual inspection) but I cannot accept that information can get
lost or that stored records get reordered (sorted by timestamp) only because
some component incorrectly converted some datatypes.


However, as negative as this may sound, I want to explicitly express that I
do respect the work that you put into the driver and that you do support
lots of people on the mailing list. I do use jaybird daily and I really
think that it is a very good and reliable piece of software. Also I have not
forgotten that you even gave me phone support once - I am still very
thankful for this. Might be that's why I have little problems accepting that
there is some small point (in my pov) fundamentally wrong...


Maybe there could be a global parameter to tell jaybird to use a utc in any
place?


Best Regards,
Steffen



[Non-text portions of this message have been removed]