EbmsUtilityTest¶
-
public class
EbmsUtilityTest
extends TestCase¶ The
EbmsUtilityTest
is the testcase forEbmsUtility
.Author: Twinsen Tsang
Methods¶
getLocalTimezone¶
testDate2UTC_Pos0¶
-
public void
testDate2UTC_Pos0
()¶ Test for converting from a java date object to UTC conformed representation string. Testing for the scenario the dateTime is represented as java calendar and under the timezone same as the machine running.
testDate2UTC_Pos1¶
-
public void
testDate2UTC_Pos1
()¶ Test for converting from a java date object to UTC conformed representation string. Testing for the scenario the dateTime is represented as java calendar and under the timezone under UTC.
testDate2UTC_Pos2¶
-
public void
testDate2UTC_Pos2
()¶ Test for converting from a java date object to UTC conformed representation string. Testing for the scenario the dateTime is represented as java calendar and under the timezone under GMT-12:00 (boundary case)
testDate2UTC_Pos3¶
-
public void
testDate2UTC_Pos3
()¶ Test for converting from a java date object to UTC conformed representation string. Testing for the scenario the dateTime is represented as java calendar and under the timezone under GMT+13:00 (boundary case)
testGMT2Date_Pos0¶
-
public void
testGMT2Date_Pos0
()¶ Test for converting from GMT datetime representation to java date object.
testMartinKalenIssue1¶
-
public void
testMartinKalenIssue1
()¶ Test for the scenario issued by Martin Kalen from the google group. QUOTED FROM martin said:
Hermes sends ebMS ACK messages with a non-standard timezone part of the timestamp (timezone info is not according to ebXML-specification, see background below) Background on #1: The recent fix for Hermes UTC timestamps uses the Java SimpleDateFormat "Z"-pattern for timezone, which is unfortunately incompatible with the ebXML specification for time zone refering to the XML schema data-type "dateTime" specified here: http://www.w3.org/TR/xmlschema-2/#dateTime Snippets from the spec: "dateTime consists of finite-length sequences of characters of the form: '-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?" "zzzzzz (if present) represents the timezone" From 3.2.7.3 Timezones The lexical representation of a timezone is a string of the form: (('+' | '-') hh ':' mm) | 'Z'" In Java the ':' character is missing between the "hh" and "mm" parts. More details on the Java SimpleDateFormat vs XSD dateTime incompatibility can be found here:
Detail: http://groups.google.com/group/cecid-hermes2/browse_thread/thread/46cca8b51ca21524
testMartinKalenIssue2¶
-
public void
testMartinKalenIssue2
()¶ Test for the scenario issued by Martin Kalen from the google group.
I live in the UTC+02:00 timezone and today at 14:01 my time (=12:01 UTC time) an incoming ebXML message with the following TTL timestamp was considered expired by Hermes: "2007-07-10T12:04:14Z". Without the change in EbmsUtility above, Hermes regards the incoming timestamp as 12:04 in my timezone which mutates the expected 12:04:14UTC to 10:04:14UTC = incorrect expiry notification to the sender.
Detail: http://groups.google.com/group/cecid-hermes2/browse_thread/thread/46cca8b51ca21524
testUTC2Calendar_Neg0¶
-
public void
testUTC2Calendar_Neg0
()¶ Test the conversation from UTC to java calendar object negatively. Testing for the scenario all invalid UTC format representation.
testUTC2Calendar_Pos0¶
-
public void
testUTC2Calendar_Pos0
()¶ Test the conversation from UTC to java calendar object. Testing for the scenario the dateTime is represented as UTC and under the timezone in UTC (GMT+00:00) using ‘Z’ designator.
testUTC2Calendar_Pos1¶
-
public void
testUTC2Calendar_Pos1
()¶ Test the conversation from UTC to java calendar object. Testing for the scenario the dateTime is represented as UTC and under the timezone in UTC (GMT+00:00) using +00:00
testUTC2Calendar_Pos2¶
-
public void
testUTC2Calendar_Pos2
()¶ Test the conversation from UTC to java calendar object. Testing for the scenario the dateTime is represented as UTC and under the timezone GMT+08:00 (non zero timezone)
testUTC2Calendar_Pos3¶
-
public void
testUTC2Calendar_Pos3
()¶ Test the conversation from UTC to java calendar object. Testing for the scenario the dateTime is represented as UTC and under the timezone GMT+13:00 (boundary case)
testUTC2Calendar_Pos4¶
-
public void
testUTC2Calendar_Pos4
()¶ Test the conversation from UTC to java calendar object. Testing for the scenario the dateTime is represented as UTC and under the timezone GMT-12:00 (boundary case)
testUTC2Calendar_Pos5¶
-
public void
testUTC2Calendar_Pos5
()¶ Test the conversation from UTC to java calendar object. Testing for the scenario the dateTime is represented as UTC without millisecond and under the timezone UTC.
testUTC2Calendar_Pos6¶
-
public void
testUTC2Calendar_Pos6
()¶ Test the conversation from UTC to java calendar object. Testing for the scenario the dateTime is represented as UTC without millisecond and under any timezone other than UTC.
testUTC2Calendar_Pos7¶
-
public void
testUTC2Calendar_Pos7
()¶ Test the conversation from UTC to java calendar object. Testing for the scenario the dateTime is represented as UTC without millisecond and ‘Z’ and under any timezone other than UTC.
testUTC2Calendar_Pos8¶
-
public void
testUTC2Calendar_Pos8
()¶ Test the conversation from UTC to java calendar object. Testing for the scenario the dateTime is represented as UTC with ‘Z’ and under any timezone other than UTC.
validateCalendar¶
-
public void
validateCalendar
(Calendar cal, int expectedYear, int expectedMonth, int expectedDay, int expectedHour, int expectedMins, int expectedSecond, int expectedMillisecond, String expectedTz)¶ A common method to validate cirtical field for specified
cal
Parameters: - cal – The calendar to test against.
- expectedYear – The expected year.
- expectedMonth – The expected month.
- expectedDay – The expected day.
- expectedHour – The expected hour.
- expectedMins – The expected mins.
- expectedSecond – The expected second.
- expectedMillisecond – The expected millisecond.
- expectedTz – The expected timezone.