Executing $ date -R gives me +0300 BUT when I print the timezone global variable timezone, it shows me -7200.
Ideas what's happeninig?
It looks like the DST is NOT included AND the timezone is sign is different, but why?
timezone does not know about D(aylight)S(aving)T(ime) by defintion. Time zones are constant sections on earth all over the year (update: at least their naming was constant during the days Sandford Fleming invented them). So as referring to those by the offset to Greenwich is common, it would not make sense to add the temporary DST offset.
The different sign dues to the different view point and direction of the date/time and timezone.
The offset given by date is referring from where you are to Greenwich.
The timezone is measured to where you are from Greenwich .
Regarding the C system calls: gettimeofday() provides DST info. (Update: This in not the case for the glibc implementation)
according to my man pages timezone is set to
seconds West of GMT
and I would anderstand that like 'the more in the west you are the larger timezone becomes'. So the sign differs from date -R and also DST is not included.
You can use the struct tm * obtained by localtime() to check whether or not there is actually DST in your environment. If the field tm_isdst > 0 then it is.
Related
Using RRD in my application I am trying to find a way to execute "rrdtool fetch"
with specific timezone. In my case "Europe/Sofia" which is "+02:00" summer "+03:00" from UTC.
Get this command
rrdtool fetch test.rrd MAX -r 86400 -s -90d -e now
Is it possible to use it with timezone Europe/Sofia, which have to add 2 hours to timestamps?
If it is possible what will happen if we are in summer time, 2 or 3 hours will be added?
Internally, rrdtool works in Unixtime, and so it is timezone-agnostic. If you use 'now' then it will be the current time, whatever timezone you are in. If you give a time like "03:00" then it will be relative to the current timezone as defined by the system.
When displaying time, such as on the X-axis of a graph, then the timezone becomes important.
Note: See the rrdtool documentation for more details - https://oss.oetiker.ch/rrdtool/doc/rrdgraph.en.html
rrdtool uses the system time libraries, and so they control what timezone is used and how this is interpreted. Under Linux, you can set the TZ environment variable to select a timezone, and the libraries will use this when converting times to local format for the X-Axis or when you give times like "13:00". If you've not set anything, then you'll get your system's default, whatever that may be.
TLDR - set your timezone using the appropriate method for your operating system, and rrdtool will honour it when you specify times.
See here for the documentation showing what strftime symbols can be used in the X-Axis definition : https://oss.oetiker.ch/rrdtool/doc/rrdgraph_graph.en.html
See here for details about the AT-style time specification that can be used for the -s and -e : https://oss.oetiker.ch/rrdtool/doc/rrdfetch.en.html#AT-STYLE_TIME_SPECIFICATION
One thing to note is that, whatever timezone you are in, the RRA buckets are aligned with midnight UCT. This doesnt show much if you're in Europe, but in New Zealand you can see the 'daily' counts rolling over at midday.
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.
The time_orign_epoch,should be 1970-01-01 00:00:00,why i am getting 5:30 more?
time_origin_epoch = datetime.datetime.fromtimestamp(0)
print time_origin_epoch
1970-01-01 05:30:00
It's because you live in India!
How did I know that?
Well, a timestamp of 0 means 1970-01-01 00:00:00 UTC. Since your output shows 05:30:00, your time zone is UTC+05:30. And India is one of the few places in the world with a timezone offset which is not a whole number of hours.
When you construct a datetime in Python using fromtimestamp(), the default is to use your local timezone for the conversion. This corresponds to calling the classic C function localtime() rather than gmtime().
Running your code gives me a result that is five hours behind what it should be. This is consistent with the fact that I am in EST and am five hours behind UTC.
If you are simply looking to confirm correct output, then check your time zone, I would guess you are somewhere in Eastern Asia. However, if you need a zeroes value produced by the program itself, try resetting your timezone to UTC from the program, and running that snippet again.
From this answer:
If you are using Unix, you can use time.tzset to change the process's local timezone:
import os
import time
os.environ['TZ'] = tz
time.tzset()
You could then convert the datetime strings to NumPy datetime64's using
def using_tzset(date_strings, tz):
os.environ['TZ'] = tz
time.tzset()
return np.array(date_strings, dtype='datetime64[ns]')
I have a lot of dates with time in this format:
day.mon.year - hour:min:sec
And I need to convert this dates with time into Unix timestamp.
I used tm structure, but I can't fill those fields:
tm_wday
tm_yday
And I don't must I fill those field, because I don't know do this field have any effect to the value of Unix timestamp.
Help me to choose rigth way to calculate Unix timestamp.
P.S. Dates with time aren't current, they can be date of the 20-th century or future dates (to 2038 year).
P.P.S. I use OS Windows.
POSIX has a formula for exactly what you want:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15
tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
(tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
This works whenever you have a broken-down time in GMT, even if the underlying system's mktime, etc. functions do not use the same format time_t as "Unix timestamps".
If your original time is in local time, you can use mktime and gmtime to convert it to GMT using the system's notion of timezone rules. If you want to apply your own timezone offset rules, just do that manually before using the above formula.
If you are on unix, mktime() will get the second part of the timestamp. It ignores the tm_wday and tm_yday fields.
What is the difference between gmtime() and localtime() ?
My requirement:
I need to display the time as per the time zone of my place.
I have a time in POSIX(UTC) format in seconds. i have time zone offset(between UTC and my current place) in seconds.
I either add or subtract the time zone offset.
After this i still have the time in POSIX format.
In order to convert it to human time, should I use gmtime() or localtime(). this is because i need the date too.
Please clarify.
Thanks!
You shouldn't provide the time zone offset yourself, but rather a real time zone specification via the environment. Then, localtime will give you the localized time. (gmtime always gives you UTC.) Suppose your code looks like
struct tm time_buffer, *localtime;
localtime = localtime_r(timep, &time_buffer);
printf("The hour is %i\n", localtime->tm_hour);
, then you call your program via:
$ TZ=Europe/Berlin my-program
and get the local hour of Berlin, correctly adjusted for daylight saving time.
If you absolutely need to provide a timezone yourself, read man tzset.
gmtime is UTC—coordinated universal time. It is always the
same, everywhere. localtime is an interpretation of the local time,
as determined by the time zone and whether summer time is in effect or
not. The time zone will be determined by the environment variable TZ,
which the user should have set to his local timezone; if this variable
is not set, an implementation defined default is used: typically the
timezone where the machine is located.