I need to Convert a string say '12/12/2013 14:30:56.583' to be converted in Date Format like 2013-12-12 14:30:56.583 in Informix database.
I Used following function
to_date('12/12/2013 14:30:56.583',"%d/%m/%Y %H:%M:%S.")
But its not accepting Milliseconds , Milliseconds are important to the resulting value.
The database version is important. The behaviour of %F was recently (11.70.xC8 and 12.10.xC2) changed. In previous versions the "." dot must probably be omitted as well as the "n" qualifier.
Regards
If you check the manual you will see is missing the milliseconds at the string format.
source: http://www-01.ibm.com/support/knowledgecenter/api/content/SSGU8G_12.1.0/com.ibm.sqls.doc/ids_sqs_1542.htm
%S Second as a 2-digit integer (00 through 61). The second value can
be up to 61 (instead of 59) to allow for the occasional leap second
and double leap second.
%Fn The value of the fraction of a second, with precision specified by
the unsigned integer n. The default value of n is 2; the range of n is
0 ≤ n ≤ 5. This value overrides any width or precision that is
specified between the % and F characters.
So, this probably will work:
to_date('12/12/2013 14:30:56.583',"%d/%m/%Y %H:%M:%S.%F3")
I’m not that familiar with Informix, but I think you may be able to use the standard to_date function to convert the string value to a date and then use an addMilliseconds function to add the milliseconds.
http://pic.dhe.ibm.com/infocenter/informix/v121/index.jsp?topic=%2Fcom.ibm.netpr.doc%2Fids_net_093.htm
Related
I am running a lua script in redis something like below:
eval "return tostring(tonumber(ARGV[1]))" 0 1538409827183989630
which should return 1538409827183989630 but is returning this 1.538409827184e+18 which is dropping last few nano second digits(Its a timestamp in nano seconds)
What is the correct way to do this assuming i need nano seconds precision cause i am comparing timestamps..
Lua numbers have two subtypes, integer and float which Lua chooses automatically.
One of the few if not the only situation where you have to care about that difference is when you want to convert a number to a string.
print(1538409827183989630) will print 1538409827183989630
print(1538409827183989630.0) will print as 1.538409827184e+18
If you want to make sure you get the same output you'll have to explicitly format the string.
local int = 1538409827183989630
local float = 1538409827183989630.0
print(string.format("%d", int))
print(string.format("%d", float))
output:
1538409827183989630
1538409827183989504
You'll notice that there will be a difference between both numbers due to the float -> integer conversion.
I have inherited some code and am very new to VB.
The code is basically being fed decimal values, these are being converted into the Hex equivalent and (I think) the Format function is being used to make sure only 2 characters (i.e. a byte) are being used in another string.
The problem is this, when the Format function encounters a Hex value that Ends in an 'A', it seems to convert the string into a time format of some sort.
Example:
"4A" converts to 04:00:00
"7A" converts to 07:00:00
Here's the relevant code snippet:
Format("4A")
In the actual code I'd get a "00", as the function has the following optional additions:
Format("0A","00")
I'm assuming the "A" is some special character.
Anybody have an idea around this quirk? Thanks in advance!
A is being interpreted as AM just as P would be PM and output 16:00.
Format() is likely not the correct thing to use here, it would only pad as you want it to if the input were a number.
Better to pad after you convert the base:
hexa = Hex$(i)
If (i < 16) Then hexa = "0" & hexa
On a SAP system, ABAP version 7.40 SP05, I just encountered a failure in unit tests on string comparison, but both strings should be the same?! Turns out it's not the case, as preceding conversion from i to string seems to produce extra trailing space in one of the strings.
This code bit:
DATA(i) = 111.
DATA(s1) = CONV string( i ).
DATA(s2) = '111'.
DATA(s3) = |111|.
Produces (as seen in debugger):
S1 111 3100310031002000 CString{4}
S2 111 310031003100 C(3)
S3 111 310031003100 CString{3}
The converted one has an extra trailing space. How does this happen and how can I prevent this to happen in i to string conversions? Obviously stuff like this makes me debug for a long time to find what is up (because unless I check the hex values, the debuger does not show that extra space...).
To understand why the space is added in the first place, check the documentation on the default conversion rules that are applied by CONV:
The character "-" is set at the last position for a negative value,
and a blank is set for a positive value.
Since you can't use the formatting options of string expressions with the CONV operator, I'd suggest changing the code to use |{ i }| (which might be a good idea for other values as well, since you'll probably need some formatting options when comparing date / time values in unit tests anyway).
You cannot prevent it. The best way I found so far in ABAP is use CONDENSE s1
DATA i type i VALUE 12.
DATA idx TYPE string.
idx = i. " idx = '12 '.
CONDENSE idx. " idx = '12'.
I'm reading someone elses code and they are using %#-1 to format an integer. I can't find anything on Google since it ignores symbols. Anyone else had more experience at string formatting than me?
[NSString stringWithFormat:#"%#-1", subnumber]
Thanks!
According to the specification:
Each conversion specification is introduced by the '%' character, or by the character sequence "%n$", after which the following appear in sequence:
Zero or more flags (in any order), which modify the meaning of the conversion specification.
An optional minimum field width. If the converted value has fewer bytes than the field width, it shall be padded with spaces by default on the left; it shall be padded on the right if the left-adjustment flag ( '-' ), described below, is given to the field width. The field width takes the form of an asterisk ( '*' ), described below, or a decimal integer.
An optional precision that gives the minimum number of digits to appear for the d, i, o, u, x, and X conversion specifiers; the number of digits to appear after the radix character for the a, A, e, E, f, and F conversion specifiers; the maximum number of significant digits for the g and G conversion specifiers; or the maximum number of bytes to be printed from a string in the s [XSI] [Option Start] and S [Option End] conversion specifiers. The precision takes the form of a period ( '.' ) followed either by an asterisk ( '*' ), described below, or an optional decimal digit string, where a null digit string is treated as zero. If a precision appears with any other conversion specifier, the behavior is undefined.
An optional length modifier that specifies the size of the argument.
A conversion specifier character that indicates the type of conversion to be applied.
We're using a conversion of the first type, since there's no dollar sign in here. Note the words in sequence at the top of the above list. The # is a conversion specifier character (as mentioned here), which indicates that we should access the value passed in as an NSObject and read its description property. Since we've already reached the last bullet point, the format code actually ends after the # symbol, and as #Kevin Ballard pointed out, the -1 is parsed as literal text.
That's just going to print "NUM-1" (where NUM is the number). To give an example, if the number is 5, that will print "5-1".
When using format strings, any modifiers to the format token must occur before the format type specifier. In this case, that means any modifiers to the %# token must occur between the % and the # (though I'm not sure if there are actually any modifiers that %# accepts).
subnumber is probably object of class like NSNumber. Like we use %d for int, %f for float, %# is place holder for a refrence. In that case
NSNumber *subnumber = [NSNumber numberWithInt:5];
NSLog([NSString stringWithFormat:#"%#-1", subnumber]);
will print '5-1'
I don't understand the next thing that happens using the sprintf command.
>> vpa(exp(1),53)
ans =
2.7182818284590455348848081484902650117874145507812500
>> e = 2.7182818284590455348848081484902650117874145507812500
e =
2.7183
>> sprintf('%0.53f', e)
ans =
2.71828182845904550000000000000000000000000000000000000
Why does sprintf show me the number e rounded instead of the number and I kept at the first place?
Variables are double precision by default in MATLAB, so the variable e that you create is limited to the precision of a double, which is about 16 digits. Even though you entered more digits, a double doesn't have the precision to accurately represent all those extra digits and rounds off to the nearest number it can represent.
EDIT: As explained in more detail by Andrew Janke in his answer to this follow-up question I posted, the number you chose for e just happens to be an exact decimal expansion of the binary value. In other words, it's the exactly-representable value that a nearby floating-point number would get rounded to. However, in this case anything more than approximately 16 digits past the decimal point is not considered significant since it can't really be represented accurately by a double-precision type. Therefore, functions like SPRINTF will automatically ignore these small values, printing zeroes instead.