Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 360890 - Milliseconds not working for timeStamp
Summary: Milliseconds not working for timeStamp
Status: CLOSED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: EDT (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-13 17:13 EDT by broy2 CLA
Modified: 2017-02-23 14:17 EST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description broy2 CLA 2011-10-13 17:13:40 EDT
program milliseconds type BasicProgram{}
    myString string;
    function main()
        fTimeStamp timeStamp("yyyymmddhhmmssffffff");
        fTimeStamp = "20041112134705123456";
        myString = stringLib.format(fTimeStamp, "EEE, dd MMM yyyy hh:mm:ss:SSSSSS Z");
        SysLib.writeStdout("Should be Fri, 12 Nov 2004 01:47:05:123456 -0500 > " + myString);
    end
end

Should be:   Fri, 12 Nov 2004 01:47:05:123456 -0500
EDT returns: Fri, 12 Nov 2004 01:47:05:000000 -0500
Comment 1 Paul Harmon CLA 2011-10-14 12:11:23 EDT
After much investigating I found that there were a couple errors in the runtime code and that we need to document a restriction in EDT.


The restriction is that the runtime code uses a Calendar object to store the TimeStamp. This object can only store milliseconds. RBD was able to store microseconds. Because of this, EDT can only keep 3 digits of precision in regards to fractions of a second. So, for the testcase given, EDT can only return:

Fri, 12 Nov 2004 01:47:05:123000 -0500

I believe this is the same restriction that existed for javascript in RBD.


I have made changes to the following runtime classes to fix the other problems, and allow us to actually maintain the 3 digits:

StringLib
StrLib  (recompile/regenerated from egl source)
ETimeStamp
Comment 2 broy2 CLA 2011-10-17 11:05:37 EDT
Verified in 20111017 build.
I'm assuming this restriction is OK with everyone.
Comment 3 Jing Qian CLA 2011-10-17 12:04:25 EDT
Brenda, could you verify the behavior in javascript?

This is inconsistent from the Etimestamp.egl's api definitions, where in there, 1. it states 6 digits for fractions of seconds. 
2. it says "One separator character must appear in between each field", the example code below has no separator character. is it another bug?


/**
* {@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.
*/
static function asTimestamp(value EString in, pattern EString in) returns (ETimestamp) {@Operation{"narrow"}};