|Subject||Re: AW: AW: AW: AW: [Firebird-Java] Timezones|
> Propably you fixed some things after copy'n'paste?right, sorry.
> This seems incorrect:Correct.
> java.util.Date timeDstLocal = localCalendar.getTime();
> This fixed the second line:
> java.util.Date timeDstLocal = localDstCalendar.getTime();
> Resulting in:Which means "true" for 1 and 2, "false" for 3, right?
> Date Sun Oct 25 02:30:00 CET 2009 : 1256434200741 == 1256434200741
> Date Sun Oct 25 03:30:00 CET 2009 : 1256437800773 == 1256437800773
> Date Sun Oct 25 02:30:00 CET 2009 : 1256434200741 == 1256437800741
> Also for future testing, I changed the first line to:Ok.
> Calendar localCalendar = new GregorianCalendar(
> TimeZone.getTimeZone( "CET" ) );
> (Which makes no difference "right now" and "right here".)
> So the first line shows there in "usual" cases, jaybird works.Yes.
> The second line shows my problem: There are cases, where the encoding is notBut which ones?
> I am unsure about the third line. I never used those "translation"Yes, they are still required.
> functions. Are those required any more? (As the datetime class now has a
> Calenar in it's own...)
> Additionally I tried to understand the function of "isInvertTimeZone", whichUps, I did not see it was also used in FBStringField, will correct it
> was used earlier in some places, but is not used any more except in
> FBStringField. Maybe this needs changes, too? But I don't even really
> understand it's usage.
there too. The isInvertTimeZone is no longer used at the moment. It was
introduced as result of long discussion about how to interpret the
calendar that is passed as parameter - as a source or as a destination
The change I committed might break some applications, since only one
interpretation is used - the parameter is the destination calendar.
However, I did not hear about this parameter here for a long time, so if
there is somebody using it, he will definitely cry during beta/RC cycle.
> However this pushes me even more into forcing the interpretation ofCurrent state of affairs with timestamps in Firebird is very similar to
> timestamps as UTC (or if really required any other timezone WITHOUT DST).
> If I think about it, with different timezones (or even in one timezone
> with/without DST) days don't start at the same point in time.
> But that's what I've timestamps always seen as - a notion of a fixed point
> in time. No matter what notation is used for printing...
> I guess a lot of other users do the same.
the situation when people have their databases with NONE charset - as
long as your client and server have same settings and you do not change
anything, things work like a charm. If the timestamp in Firebird would
store timezone information as well, it would be like an UTF8 charset.
> As a failsafe solution, I am planning on placing the following to theWell, if that solves your issue, why not?
> startup class of my web application:
> System.setProperty( "user.timezone", "UTC" );
> if ( !TimeZone.getDefault().getID().equals( "UTC" ) )
> System.exit( 1 );
> A rather hard solution, but it ensures the correctness of database access.
> (Yes, I do NOT like this way either.)
> Reading more in XSQLVAR I would like to suggest, not to call the followingAt the moment it is obsolete. However there is another quite expensice
> "every time":
> Instead have a static member calling this once using a static initializer.
> Calender.getInstance() is a rather expensive function.
Calendar c = (Calendar)cOrig.clone();
I need this for translation, but I do not know if I am allowed to modify
the specified calendar...
> I thought about implementing my own getTimestamp function but I cannot get aThat can be fixed - that is not a big issue here. I could extend the
> timestamp using ResultSet.getBytes().
FirebirdResultSet and FirebirdPreparedStatement interfaces with
getRawData(int) and setRawData methods.
> For my former idea to have a switch to always use UTC for persistence I havelooks ok for the UTC case... but for the others...
> prepared some very simple converting functions [see attachment], which are
> by the way much faster than working with calendars. Internally Timestamp is
> a thin wrapper around Date and Date is a thin wrapper around long...
> I just have no idea where to place such a switch and where to place theWhat about adding "parallel" methods starting from the
> condition selection between the default implementations and the UTC
FirebirdPreparedStatement and FirebirdResultSet, additional setters and
getters for FBDateField, FBTimeField and FBTimestampField, which then
call your extensions of XSQLVAR code? That could be added to Jaybird.
Then two possibilities exist - one is to add some connection parameter
that would make the "normal" setTimestamp methods to delegate to
setTimestampUTC, or create a thin proxy layer that would do this
delegation transparently. I prefer latter.