I try to extract local time including time zone and format this in a format similar to the following
2019-11-06T00:39:21.25+02:00 with precision of milliseconds.
Any idea how to do this?
Related
Reference: https://github.com/offa/influxdb-cxx
It is easy to delete record by time using CLI interface,
delete from imagetable where time='2022-11-16T19:42:41.945508272Z'
but I am not able to figure out how to do the same with influxdb-cxx. i.e. not able to access the time through C++ interface.
e.g. Tags can be accessed with function points[0].getTags() but how to access the time ?
Have already tried to access it with points[0].getTimestamp() but not able to print it in this format in C++ 2022-11-17T03:37:25.934547412Z
can anyone please help ? Thanks in advance.
In influxdb-cxx you can use InfluxDB::execute method to execute InfluxQL statements like from your example for CLI interface. Regarding timestamps, they are saved as std::chrono::time_point<std::chrono::system_clock> (source) in the library's Point class, which denotes Unix (epoch) time excluding leap seconds (which is what timestamps in InfluxDB represent). Your example uses RFC3339 notation to provide timestamp, but InfluxQL also directly understands "nanosecond count since epoch" notation for it (example). So, it isn't necessary to represent Point's timepoint in RFC3339 notation to use it in execute command (which is possible, but harder and reduntant), you can just use standard C++ chrono library functions to get nanoseconds since epoch for given timepoint. Example:
using namespace std::chrono;
auto nsEpoch = duration_cast<nanoseconds>(points[0].getTimestamp().time_since_epoch()).count();
idb->execute("delete from imagetable where time=" + std::to_string(nsEpoch));
One of my source table(oracle) date column having the value 5/3/2013 6:00:51.134000000 AM. I am trying to pull the same into to my target(oracle), but my target converted the micro seconds as "zeros" and loading the value 5/3/2013 06.00.51.000000000 AM. Both my source & target column has declared as timestamp. I have set the date format like MM/DD/YYYY HH24:MI:SS.US in session properties
Can anyone help to me to get the date with micro seconds? I am using informatica 10.2.0 Thx
You can try the workaround suggested at the below link to process high precision dates. You will need to modify the source and target definition field lengths to (29,9).
Link
The way to resolve this is to increase the precision of the source or target definition to precision 29 and scale 9 after the source/target is imported into Informatica. This will handle the digits in milliseconds without converting them to all zeros.
I am referring the documentation of _filefirst() and _findnext() APIs here
These APIs return file information in a _finddata_t structure. I need to access file modification time from time_write element. Though documentation says that
time is stored in UTC format (It is a times stamp). Documentation doesn't clarify if this time represents local time or UTC time. It seems to me that time_write doesn't return the UTC time instead its value is influenced by the system time zone settings.
My Question is - Does time_write returns local time represented in the UTC timestamps ?
Edit1
Here I explain what actually I am trying to understand. My system is in IST timezone. Now, there is a file emp10.ibd for which windows shows
Date Created - 10/21/2016 10:51 AM
Date Modified -10/21/2016 10:51 AM
I used epoch converter to find out the the epoch timestamp for which it turn out to be as following -
Now if I retrieve the time_write element from _finddata_t structure which has been returned by _findnext() for the same file i.e. emp10.ibd. I expect the returned timestamp should be close to
Epoch timestamp 1477027260 as shown in the image above.
But I get the time_write as 1477043509
If I again use epoch converter I get the following
I am trying to understand why there is 4:30 Hours of time difference in GMT in both images shared above? IMO timestamp should have been almost same. What obvious I am missing here ?
Edit2
For those folks who were asking for sample code. Here I paste link of another post which I had asked a year ago for the same reason but scenario was little different, There I was referring to _stati64 struct. I didn't troubleshoot the problem further at that time. By now it is pretty clear that
_finddata_t and _stati64 APIs are affected by _tzset environment variable as Harry mentioned in this post while FILETIME struct is not.
Local time is UTC plus a geographical offset plus potentially a seasonal offset. A UTC timestamp has no such offsets.
In this particular case, the exact format is seconds since1970-01-01T00:00:00Z i.e. January 1st, 1970, at midnight UTC.
To troubleshoot further, next I used GetFileTime API to retrieve the
the file modification time in FILETIME struct and converted the time into UTC timestamp. I got the time according the time set on my computer. I was expecting the same.
At this point I started investigating the way we execute our program through a perl script. I found that perl script was setting the timezone to GMT-1.
Since my computer was in timezone GMT+5:30, therefore I used to get resultant +04:30 hrs of difference as mentioned in the original post.
Therefore I would like to sum up my experience as - the outcome of _finddata_t strcut is affected by the timezone set in the session but the outcome of FILETIME struct is not affected by the time zone set in the session, instead it is the time according the system timezone. Since I was retrieving one time using FILETIME struct and another using _finddata_t strcut that was causing the problem. Took me ~48Hrs to find out this interesting observation.
Why does that happen? Perhaps the answer is provided by Harry in the comment section.I am pasting the same here as it is -
changing the timezone in Perl is probably causing the TZ environment variable to be set, which affects the C runtime library as per the documentation for _tzset. It isn't a per-session setting, at least not in the way Windows uses the word "session"."
Edit1
From File Times, I read the following -
FindFirstFile retrieves the local time from the FAT file system and converts it to UTC by using the current settings for the time zone and daylight saving time.
Though I was using the NTFS file system but I believe it uses the same mechanism i.e. retrieve the local time from file system and converts it to UTC by using current settings. That's the reason I noticed the difference.
I am trying to save a file into a directory of files based on the current date and time. I am trying to get the format of the following:
"FullMonth-FullYear" example:
"April-2011"
"FullMonth-littleDay-year" example:
"March-7-11"
hour-minutes-seconds. example: "18:05:09" in 24 hour format
It depends on the format you have the time in right now. I'm a big fan of sprintf(), and since I mostly deal with big piles of seconds, milliseconds, or nanoseconds, I do a lot of modulus arithmetic to get what I want.
boost.date_time can do arbitrary formatting, to a higher a degree of precision than the standard functions are typically capable of. Specifically, see Date Time Input/Output Format Flags.
I'm using Qt to parse an XML file which contains timestamps in UTC. Within the program, of course, I'd like them to change to local time. In the XML file, the timestamps look like this: "2009-07-30T00:32:00Z".
Unfortunately, when using the QDateTime::fromString() method, these timestamps are interpreted as being in the local timezone. The hacky way to solve this is to add or subtract the correct timezone offset from this time to convert it to "true" local time. However, is there any way to make Qt realize that I am importing a UTC timestamp and then automatically convert it to local time?
Do it like this:
QDateTime timestamp = QDateTime::fromString(thestring);
timestamp.setTimeSpec(Qt::UTC); // mark the timestamp as UTC (but don't convert it)
timestamp = timestamp.toLocalTime() // convert to local time
try using the setTime_t function.
Note that full time zone support is not available yet in Qt, but probably will in future versions.
http://bugreports.qt-project.org/browse/QTBUG-10219