Project

Profile

Help

Forums » Help »

calling Java setter from XSLT

Added by Anonymous about 16 years ago

Legacy ID: #5256284 Legacy Poster: Christian Jacob (cjacob_de)

Hi, I have to process some time-related data. The source is delivering it at UTC, but I have to transform it to my local timezone. Since xslt has no timezone-shifting capability, I try to solve this via Java extensions. The trick should be fairly simple: I have to create a Java object of the class SimpleDateFormat, pass to it an UTC timezone, and parse the date to be transformed. However, the setting of the UTC timezone has no effect on the formatter. See the following script: <xsl:variable name="tzUTC" select="TimeZone:getTimeZone('UTC')"/> <xsl:variable name="fmtFrom" select="DateFormat:new('yyyyMMddHHmm')"/> <xsl:variable name="void0" select="DateFormat:setTimeZone($fmtFrom, $tzUTC)"/> <xsl:message><xsl:value-of select="DateFormat:getTimeZone($fmtFrom)"/></xsl:message> the result that is printed on the console still shows my local timezone and not the expected UTC timezone: sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]] Has anyone a clue what went wrong? How do I make the invocation of setTimeZone work? Many thanks in advance! Regards, Christian


Replies (1)

RE: calling Java setter from XSLT - Added by Anonymous about 16 years ago

Legacy ID: #5256314 Legacy Poster: Michael Kay (mhkay)

Like most functional languages, Saxon uses lazy evaluation, which means that things are not evaluated in the order they are written; and variables whose value is never used are never evaluated. I think the best answer to this is to write some Java code that encapsulates your sequence of calls into something that is a pure function without side-effects, and then call this function from XSLT. However, an alternative approach is to call the Java setter in a place where Saxon would use the result if there were one - for example, in xsl:value-of while writing to the main result destination. (Saxon could detect that the Java method returns nothing and therefore doesn't need to be called, but it carefully refrains from doing so.) (Perhaps there is an even better answer: are you really doing anything that needs a call to Java at all? XSLT 2.0 has very rich date-and-time handling built in.)

    (1-1/1)

    Please register to reply