Community
Participate
Working Groups
Created attachment 205662 [details] Eunit variations Intialization of a timestamp reference with a string literal causes an exception: 'undefined' is null or not an object I've attached an eunit test file
Matt, Brian, I can make the attached testcases work by assuming the format is "yyyy-MM-dd HH:mm:ss", but I doubt that's the right answer given that the Java RT has logic that will parse out the string trying to extract as much timestamp info as it can in the absence of a specific format. I don't believe the old RBD RT had anything like that, so I need guidance on whether we need to implement the equivalent of what the Java RT is doing.
*** Bug 360411 has been marked as a duplicate of this bug. ***
*** Bug 360408 has been marked as a duplicate of this bug. ***
Scott, it may be dangerous to go by what the Java RT is doing. There's no guarantee that it's working properly yet. The assignment statements in testFunctionParameterIn2 are invalid. We must know the format of the timestamp in order to parse the string properly, so when the timestamp is declared without a format the conversion can't be performed. This is mentioned in item C of http://wiki.eclipse.org/EDT:EGL_Language_Primitive_Type_Conversions The assignment statements in testFunctionParameterIn3 should be performed according to the description of ETimestamp.asTimestamp(EString, EString). /** * {@Operation narrow} Converts a string to a timestamp. The string is parsed * by searching for the timestamp fields specified in the pattern, in order * from years down to fractions of seconds. Each field from the pattern must * be present in the string. Years must be represented with four digits, * fractions of seconds with six digits, and other fields with two digits. * One separator character must appear in between each field. Any character * may be used as a separator, and the separators do not have to match. * * @throws TypeCastException if the string can't be parsed into a timestamp or the pattern is invalid. */ In other words, when you assign a string to a timestamp("yyyyMMddHHmmss"), the string must contain four year digits, and two digits for the months, days, hours, minutes, and seconds. There must be one character between each of these fields. The conversion must fail (throw a TypeCastException) if the string isn't in this format.
Matt, thanks for the info -- that's what I needed to know in order to resolve this bug. Changing priority to p1 because this is a fundamental issue that must be addressed and because this seems to be blocking a number of eunit tests (including some that aren't directly related to timestamps).
Resolved indirectly Verified by Pengfei
Verified with 20111114_2101 & closed.
