Suppose i have a FILETIME which has some value (which we can see by converting it to systemtime) when I am in timezone1. Suppose I changed my timezone to timezone2.
Now I want to get the time in hours and minutes (format) which was in timezone1.
A simple way would be to convert it to system time then use SystemTimeToTzSpecificLocalTime to convert the time to a timezone specific time.
Related
Which one is best to use, DateTime or INT (Unix Timestamp) or anything else to store the time value?
I think INT will be better at performance and also more universal, since it can be easily converted to many timezones. (my web visitors from all around the world can see the time without confusion)
But, I'm still doubt about it.
Any suggestions?
I wouldn't use INT or TIMESTAMP to save your datetime values. There is the "Year-2038-Problem"! You can use DATETIME and save your datetimes for a long time.
With TIMESTAMP or numeric column types you can only store a range of years from 1970 to 2038. With the DATETIME type you can save dates with years from 1000 to 9999.
It is not recommended to use a numeric column type (INT) to store datetime information. MySQL (and other sytems too) provides many functions to handle datetime information. These functions are faster and more optimized than custom functions or calculations: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html
To convert the timezone of your stored value to the client timezone you can use CONVERT_TZ. In this case you need to know the timezone of the server and the timezone of your client. To get the timezone of the server you can see some possibilites on this question.
Changing the client time zone The server interprets TIMESTAMP values
in the client’s current time zone, not its own. Clients in different
time zones should set their zone so that the server can properly
interpret TIMESTAMP values for them.
And if you want to get the time zone that a certain one you can do this:
CONVERT_TZ(#dt,'US/Central','Europe/Berlin') AS Berlin,
I wouldn't store it in int, you should check out MySQL Cookbook by Paul DuBois he covers lot's of things in it.Also there is a big portion about your quetion.
In Informatica Cloud i am trying to convert current system datetime to milliseconds.
This is not working as expected
TO_CHAR( Systimestamp() ,'YYYYMMDDHH24MISS')
Please Help
Below link might be helpful for you in understanding more about conversion of timestamps.
Convert string datetime to Informatica datetime
After spending some significant amount of time, I could not figure out how to convert UDate from one timezone to another. Here is the problem I am trying to solve :
I have a timestamp which is number of milliseconds since epoch. This is a timestamp in UTC. I want to convert this timestamp to a timestamp at some local time zone (e.g. US/Eastern). I want to extract number of days since epoch and number of milliseconds since from converted timestamp. I want to use icu library to do this.
I tried to create a UDate from number of milliseconds since epoch in UTC. I can create a timezone instance for the given timezone.
TimeZone *tz = TimeZone::createTimeZone("US/Eastern");
How do I convert UDate from UTC to the given timezone and extract the answers I want? Could it be done using icu?
Any help will be greatly appreciated.
I want … number of days since epoch and number of milliseconds since from converted timestamp.
I think these will be the same regardless of time zone, won't they?
Or can you give an example of the result you would like to see (before vs. after)
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 know that SystemTimeToTzSpecificLocalTime API can convert from UTC time to local time, but it takes time in SYSTEMTIME format. I'm curious if there is an API that accepts FILETIME format instead?
PS. I know that I can achieve this by using FileTimeToSystemTime() and then SystemTimeToFileTime(). I was just trying to save two steps for converting to SYSTEMTIME and back.
Have a look at FileTimeToLocalFileTime()
Converts a (UTC-based) file time to a local file time.
And LocalFileTimeToFileTime():
Converts a local file time to a file time based on the Coordinated Universal Time (UTC).
However, you cannot convert between a UTC FILETIME and a local FILETIME in a specified timezone. The current timezone of the local machine is used for the conversion. The documentation states:
To account for daylight saving time when converting a file time to a local time, use the following sequence of functions in place of using FileTimeToLocalFileTime:
1. FileTimeToSystemTime
2. SystemTimeToTzSpecificLocalTime
3. SystemTimeToFileTime
And
LocalFileTimeToFileTime uses the current settings for the time zone and daylight saving time. Therefore, if it is daylight saving time, this function will take daylight saving time into account, even if the time you are converting is in standard time.