[Mulgara-dev] XSD Date/Time Corruption reproducible

[Paul Gearon]

I was about to comment that a one hour difference was too big a coincidence
to ignore the possibility of a timezone (or DST) issue.  This is despite the
fact that other observed differences have been significantly different.

I was also going to comment that the relevant code is in:
src/jar/store-stringpool/java/org/mulgara/store/stringpool/xa/SPDateTimeImpl.java

But then I thought it was just too lazy of me to not look at the code myself
before posting.

The problem would seem to be in encoding/decoding, so I tried pulling the
relevant java files out, and into a test area where I could look at them in
peace.  I then wrote a test class, and found the following:

String datestring = "1981-04-26T02:56:00";
System.out.println("Normal form:  " + datestring);
SPDateTimeImpl dti = SPDateTimeImpl.newInstance(datestring);
System.out.println("Lexical form: " + dti.getLexicalForm());

Gives the following output:
Normal form:  1981-04-26T02:56:00
Lexical form: 1981-04-26T03:56:00

Gak.

When I change the original string to "1981-04-26T03:56:00" then the output
becomes:
Normal form:  1981-04-26T03:56:00
Lexical form: 1981-04-26T03:56:00

Double Gak.

After looking at the internal data structures, I narrowed it down the parser
in newInstance.  Unfortunately, the bug here is in a third party date parser
from Mouse Pushers (which I'd never heard of before today).  If you try the
following code:

Date date = DateParser.parse(
        "1981-04-26T02:56:00.000",
        "yyyy-MM-dd'T'HH:mm:ss.SSS",
        Locale.getDefault());
System.println(date.toString());

Then the output is:
Sun Apr 26 03:56:00 CDT 1981

Note that the hour has changed from 2 to 3.  It doesn't get changed when the
time starts at 3:56.  I suspect you will find that all of your problem dates
will show up incorrectly from this parser.

So it's not Mulgara's fault!!!  :-)

Unfortunately, there is no more recent version of this parsing library, so
we either have to debug the source code ourselves (
http://www.mousepushers.com/java.html) or else we find/write another date
parser.  Anyway, I'm *supposed* to be working, so I have to leave it here
until tonight.

Regards,
Paul

On 1/25/07, Tate Jones <tate at bluedog.com.au> wrote:
>
> I would have to agree.  Looks like a locale issue.
>
> Write the same query with a less than constraint on the input time.
>
> On 25/01/2007, at 7:48 AM, David Wood wrote:
>
> > On 23 Jan2007, at 17:17, Andrae Muys wrote:
> >>> Somehow, T02:56:00 becomes T03:56:00.  I have been trying to
> >>> determine
> >>> where exactly this happens so that I can turn logging on for that
> >>> module.  Right now I have logging on for
> >>> org.mulgara.resolver.store.StatementStoreResolver and
> >>> org.mulgara.itql.ItqlInterpreter.
> >>
> >> Well whatever is happening it is unlikely to ItqlInterpreter, but
> >> it is the entry point to the system.  It's also not going to be
> >> the Resolver - as that only works in localspace so unless you are
> >> also inserting T03:56:00 no amount of corruption of the statement-
> >> store could produce the results we are seeing.
> >>
> >> The place to start looking is in the localisation/globalisation
> >> code - so that is LocalizedTuples, StringPoolSession, and
> >> GlobalizedAnswer, and move out from there.
> >
> > Umm, why couldn't this be related to Java's handling of Daylight
> > Savings Time?  Or a Java localization issue?  The odd thing about
> > that is that an hour is *added*, not subtracted.
> >
> > Can you duplicate this problem on a machine with the *hardware*
> > clock set to GMT and the OS system clock matching in GMT?  Does it
> > still occur?
> >
> >
> > Regards,
> > Dave
> >
> > --
> > http://prototypo.blogspot.com
> >
> >
> >
> > _______________________________________________
> > Mulgara-dev mailing list
> > Mulgara-dev at mulgara.org
> > http://mulgara.org/mailman/listinfo/mulgara-dev
>
> Tate Jones
> tate at bluedog.com.au
>
>
> _______________________________________________
> Mulgara-dev mailing list
> Mulgara-dev at mulgara.org
> http://mulgara.org/mailman/listinfo/mulgara-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-dev/attachments/20070125/dc9f0de8/attachment.htm>