UPDATE: The "fraction of a second" parameter to Timestamp's constructor actually takes nanoseconds... I guessed it was hundredths of a second and my low values were rounded away. Question left for reference....
I'm struggling with Oracle's C++ library - OCCI. Summarily:
creating Timestamp objects and verifying they're good to hundredths of a second (though I'd like more!)
using stmt.setTimestamp then executeUpdate() to insert into a TIMESTAMP(6) column which should preserve microseconds
selecting the row in Oracle SQL Developer: the sub-second component is always 0-ed e.g. 14-JUL-11 06.03.27.000000000.
Problem
I need subsecond precision - hopefully microseconds! We've put a lot of work into capturing that precision in our servers and need (at least some of) it for analysis.
Details
I create a Timestamp from year/month/day hour/minute/second/millisecond, reducing the last to hundredths of a second as that seems to be what the constructor supports. (No Oracle documentation I can find specifies the interpretation, but in a fromText example "xff" clearly corresponds to a ".##" hundredths suffix in the value to convert. What's the point of TIMESTAMP(6) supporting 6 decimal places if you can't insert them?)
oracle::occi::Timestamp temp =
oracle::occi::Timestamp(_env, year, month, day,
hour, minute, second, millisecond / 10);
// re-extract the broken-down time from temp to prove it's stored successfully
int ye;
unsigned mo, da, ho, mi, se, fs;
temp.getDate(ye, mo, da);
temp.getTime(ho, mi, se, fs);
return temp;
Here, fs gets the milliseconds/10 value as expected.
I use this as in:
oracle::occi::Timestamp ts;
ts = _pImpl->makeOracleTimestamp(p->ATETimeStamp);
stmt.setTimestamp(11, ts);
Where field 11 is a TIMESTAMP(6).
Selecting the row in Oracle SQL Developer, the other parts of the timestamp column are correct but the sub-second component is 0-ed ala 14-JUL-11 06.03.27.000000000.
Any insight much appreciated!
(If relevant, using MSVC++ 2005, Oracle 10.2.0.4 sdk, SQL Developer 3.0.04 - please ask if something else might be relevant).
Thanks,
Tony
Turns out the "fractional seconds" field is nominally in nanoseconds rather than hundredths. I wish Oracle would say that in their documents! I say nominally because if it really preserved the least-significant digits then the hundredths values I had would have appeared as a number of nanoseconds and I might have immediately guessed at the problem - instead it seems values < 100 nanoseconds are lost anyway (and perhaps bigger - I haven't probed the cut-off point).
Thanks to anyone who had a look at the question or tried some research / investigation.
Related
I need to pull a date out of a string. Since not everyone uses the official ISO format when printing their dates, it is impractical to write a date parser for every possible date format that could be used, and I need to handle as many date formats as possible - I don't control the data and can't expect it to come in a specific format.
This seems like a problem that has probably already been solved ages ago, but my Google-fu is too weak to find the solution. :(
Does there already exist a C++ library that, given a string, will return the month, day, year, hour, minute, second, etc that is referenced in that string, if any?
Pseudocode:
string s1 = "There is an expected meteor shower this Thursday,"
"August 15th 2013 at 4:39 AM.";
string s2 = "20130815T04:39:00";
date d1 = magicConverter(s1);
date d2 = magicConverter(s2);
assert(d1 == d2);
You might use the code from here, but you need to configure a mask, that tells the code which time format is used. If you write a class routine, that takes a mask and a string and gets you out the time and is able to print in any format you like, you should be well prepared. You have to look in more detail, if it also supports Daynames and Monthnames. I got it to work in python with a module providing a function that seems pretty much the same.
For more detail:
Please look at the example 2013-08-03 again. Nobody and as follows no computer is able to tell you if this date belongs to August or April, except of having a mask telling JJJJ-MM-DD or JJJJ-DD-MM. Also this library may tell you only standard masked times. So it might lead you to August in this case. But as you said it can be any date declaration, thus it does not need to follow standards, thus it can also mean March. An other possibility is to tell you about the date from the context (e.g. a table with a column of all te same time formats by looking for the increase (which would also fail if you just look at one day per month for just one year).
Another example... if I ask you 2013-05-04... to which month does it belong? You might tell me... April. I would reply "no, to the 4th of May" and vice versa for May and 5th of April. If you tell me how to solve this puzzle with two possible solutions I would understand your downvote... please think before downvoting someone trying to help you.
I'm fighting a few days with COleDateTime in MFC.
I have CTime with correct values. Correct years, days, months, hours, minutes and seconds.
I tried a few ways to convert CTime to COleDateTime:
-1.I put CTime data to constructor of COleDateTime
COleDateTime(int nYear,int nMonth,int nDay, int nHour, int nMin,int nSec );
-2. I formatted CTime to time.Format("%m/%d/%y %H:%M:%S");
and passed to ParseDateTime of COleDateTime.
-3. Also I tried to use SetDateTime of COleDateTime
After that I'm getting incorrect values of minutes 1-2 min. more or less.
I have never seen it before and I couldn't find nothing in internet.Everybody says abot loss precision but this a second, not a minute.
Please advice something for me!
Thank you
I think the problem is that COleDateTime internally uses a float for storage, and the value represents the number of days since 30 December 1899.
As the number of days gets larger, the precision of the smaller fields (like minutes) decreases. For example, a float can accurately store the values 1000000 and 0.0000001, but it CAN'T store 1000000.0000001. It doesn't have enough bits of precision.
This limitation is hinted at in the MSDN documentation:
This type is also used to represent date-only or time-only values. By convention, the date 0 (30 December 1899) is used for time-only values. Similarly, the time 0:00 (midnight) is used for date-only values.
So basically, if you want a precise time, set the date to 30 December 1899.
It seems like Microsoft could have just designed this class to store the "days" portion as an integer, but hey, that would be too EASY.
One of my c++ function does some calculations based off of the values of other variables. The program asks for a bunch of information including start date and end date for 2 separate events.
p1.start_date and p2.start_date; p1.end_date and p2.end_date each of which have a day, month and year stored inside.
I need to set combined.start_date to which happens earlier (p1.start_date or p2.start_date) and I need to set combined.end_date to which happens later.
Could I please have some help in getting this started? Here is what I have now: http://pastebin.com/huJprtHj.
At least assuming the dates involved are reasonably current1, stuff the month/day/year into a struct tm and use mktime to convert to a timt_t, then you can compare the two time_ts directly.
If you need/want to support a wider range of dates, you might consider Ray Gardner's Julian Date routines.
At least in a typical case, dates from 1970 to at least 2038 will work.
Generally, calculations based on dates can be done in two ways.
Convert the date into a "number of days since some fixed date (e.g. 1 Jan 1970)".
Use the date components (year, month, day).
If this is all you need to do, just comparing each part (with the "highest first") will work just fine - you just need a compare function that can tell you if date1 is less than date2.
The rest of your question should be really simple programming.
Edit: to clarify: For DATE calculations, days from a set date is fine. The system library functions have functions that use seconds [and in some systems, fractions of a second] for a complete time down to seconds. This is not required for comparing dates where a the time of day is not involved.
Make this function. I'm guessing that your dates are stored in an object named Date, since you don't specify.
bool operator< ( const Date& left, const Date &right )
{
// ...
}
Then you can compare your date objects the same as if they were built-in types like int.
I'm creating a mock object to test my application so that it works at the boundary conditions of time. I'm using FILETIME in the Windows SDK.
The link shows the earliest time which is January 1, 1601 (I'm assuming midnight 00:00:00 and both dwLowDateTime and dwHighDateTime are 0x00000000), so I have that. What is the latest possible FILETIME?
My first instinct is to set dwLowDateTime and dwHighDateTime to 0xFFFFFFFF, but then I questioned if that really is a valid time that I need to test, due to where my linked page says the SetFileTime function uses 0xFFFFFFFF to specify that a file's previous access time should be preserved.
My understanding is that FILETIME was made to represent any valid SYSTEMTIME in 64 bits. If you take the limit of SYSTEMTIME (last millisecond in 30827) then you end up with a FILETIME of 0x7fff35f4f06c58f0 by using SystemTimeToFileTime().
However, if you put 0x7fffffffffffffff into FileTimeToSystemTime() then you will end up in the year 30828, although this date is invalid for SYSTEMTIME. Any larger value (0x8000000000000000 and above) causes FileTimeToSystemTime() to fail.
All in all, I would recommend not to go beyond 0x7fff35f4f06c58f0 in order to stay compatible with SYSTEMTIME.
According to the link, FILETIME represents:
...the number of 100-nanosecond intervals since January 1, 1601 (UTC).
so not Jan 1st 1970.
It also says
...the SetFileTime function [for example] uses 0xFFFFFFFF to specify that a file's previous access time should be preserved.
So I don't think you would expect 0xFFFFFFFF to be a valid max value.
According to patent 6853957, the range is 30,000 years before/after the epoch (Jan 1, 1601). That implies you can use it with negative dates (i.e. dates before the epoch) too.
EDIT: Just calculated: it can store (approx) 58,454 days worth of 100-nanosecond intervals, so +/- 30,000 years sounds like a good value to go with, if you accept negative dates of course.
There is an answer in this MSDN article - Test Cases for the RTC Real-Time Functions Test:
The test looks for the range beginning with the minimum possible FILETIME (FILETIME 0 is the start of Jan 1st 1601) and end with maximum possible FILETIME (Max FILETIME is the maximum 64-bit value).
I'm currently implementing a histogram that will show a very large scale data using Qt and I have some doubts about which data structure(s) I should be using for my problem. I will be displaying the amount of queries received from users of an application and the way I should display is as follows -in a single application that will show different histograms upon clicking different "show me this data etc." buttons-
1) Display the histogram of total queries per every month -4 months of data here, I
kept four variables and incremented them as I caught queries belonging to those months
in the CSV file-
2) Display the histogram of total queries per every single day in a selected month -I was thinking of using 4 QVectors to represent the months for this one, incrementing every element of the vector (day), as I come by that specific day -e.g. the vector represents the month of August and whenever I come across a data with 2011-08-XY , I will increment the (XY + 1)th element of that vector by 1- my second alternative is to use 4 QLinkedList's for the sake of better complexity but I'm not sure if the ways I've come up with are efficient enough and I'm willing to listen to any other idea.
3) Here's where things get a bit complicated. Display the histogram of total queries per every hour in a selected day and month. The data represented is multiplied in a vast manner and I don't know which data structure -or combination of structures- I should use to implement this one. A list of lists perhaps?
Any ideas on my problems at 2) and 3) would be helpful, Thanks in advance.
Actually, it shouldn't be too unmanageable to always do queries per hour. Assuming that the number of queries per hour is never greater than the maximum int value, that's only 24 ints per day = 32 bits or 64 depending on your machine. Assuming 32 bits, then you could get up to 28 years worth of data per MB.
There's no need to transfer the month/year - your program can work that out. Just assign hour 0 to the earliest point in your data, which you keep as a constant, then work out the date based on hours passed since then.
This avoids having to have a list of lists or anything fancy - just use an array where each address contains the number of hours since hour 0, and the number of queries for that hour.
Why don't you simply use a classical database?
When you start asking these kind of question I think it is a good time to consider a more robust structure.There are multiple data structures implemented inside any DB, optimized either for different access type. You should considerate at least lookup, insertion, deletion, range queries. There is no structure which is better than the others in all costs, so there is always a trade-off.
Qt has some database classes you can use. I never used the Qt SQL library, but I think you should give it a shot. Fortunately, there is a Qt SQL programming guide at the end of the page linked.