In most of the examples I had seen:
time_zone_ptr zone( new posix_time_zone("MST-07") );
But I just want to get the current time zone for the machine that runs the code. I do not want to hard code the time zone name.
Plain posix: call tzset, use tzname.
#include <ctime>
tzset();
time_zone_ptr zone(new posix_time_zone(tzname[localtime(0)->tm_isdst]));
Posix with glibc/bsd additions:
time_zone_ptr zone(new posix_time_zone(localtime(0)->tm_zone));
The above are abbreviated Posix timezones, defined in terms of offset from UTC and not stable over time (there's a longer form that can include DST transitions, but not political and historical transitions).
ICU is portable and has logic for retrieving the system timezone as an Olson timezone (snippet by sumwale):
// Link with LDLIBS=`pkg-config icu-i18n --libs`
#include <unicode/timezone.h>
#include <iostream>
using namespace U_ICU_NAMESPACE;
int main() {
TimeZone* tz = TimeZone::createDefault();
UnicodeString us;
std::string s;
tz->getID(us);
us.toUTF8String(s);
std::cout << "Current timezone ID: " << s << '\n';
delete tz;
}
On Linux, ICU is implemented to be compatible with tzset and looks at TZ and /etc/localtime, which on recent Linux systems is specced to be a symlink containing the Olson identifier (here's the history). See uprv_tzname for implementation details.
Boost doesn't know how to use the Olson identifier. You could build a posix_time_zone using the non-DST and DST offsets, but at this point, it's best to keep using the ICU implementation. See this Boost FAQ.
Quite late in the day, but I was looking for something similar so this can hopefully help others. The following (non-boost) way using strftime seems to work on most platforms:
time_t ts = 0;
struct tm t;
char buf[16];
::localtime_r(&ts, &t);
::strftime(buf, sizeof(buf), "%z", &t);
std::cout << "Current timezone: " << buf << std::endl;
::strftime(buf, sizeof(buf), "%Z", &t);
std::cout << "Current timezone: " << buf << std::endl;
Or one can use std::time_put for a pure C++ version.
Well, maybe you could do it using the GeoIP library. I know it's a bit of an overkill, but since most computers in the world are connected to the internet, you could probably get away with it. According to the guy I'm developing for, it's been over 99% accurate.
Note: This is a dumb idea. I am just stretching for answers.
In order to properly answer this question, it's important to understand that the time zone support in Boost is severely limited.
It's primarily focused on POSIX time zones, which have several limitations. These limitations are discussed in the POSIX section of the timezone tag wiki, so I won't repeat them here.
It has functions that work with IDs of IANA/Olson time zones, but it artificially maps these to POSIX values - which has the effect of flattening the time zone to a single point in history. These mappings are stored in a csv file in the Boost source code.
The csv file hasn't been updated since April 2011, and there have been many changes to time zones since then. So, the mappings it does have are somewhat inaccurate.
In general, I would not recommend Boost for working with time zones. Instead, consider the ICU TimeZone Classes, which are part of the ICU project. You will find these to be fully portable, and they have full and correct time zone support.
It's worth mentioning that ICU is used in many popular applications. For example, the Google Chrome web browser gets it's time zone support from ICU.
In ICU, the current local system time zone is available as the default time zone. You can read more in the section "Factory Methods and the Default Timezone" in the ICU documentation.
You could always try getting the universal time and local time from boost and checking the difference, it's probably full of caveats though.
Related
In Python or Java you can get the UTC offset (at present time) given the IANA name of the timezone ("America/Los_Angeles" for instance). See Get UTC offset from time zone name in python for example.
How can you do the same using C/C++ on Ubuntu 14.04?
EDIT: Preferably in a thread-safe way (no environment variables).
You alluded to this fact, but it's important to note that the offset between UTC and the time in a time zone is not necessarily constant. If the time zone performs daylight saving (summer) time adjustments, the offset will vary depending on the time of year.
One way to find the offset is to take the time you're interested in, hand it to the localtime() function, then look at the tm_gmtoff field. Do this with the TZ environment variable set to the zone name you're interested in. Here's an example that does so for the current time:
#include <time.h>
#include <stdio.h>
int main()
{
setenv("TZ", "America/Los_Angeles", 1);
time_t t = time(NULL);
struct tm *tmp = localtime(&t);
printf("%ld\n", tmp->tm_gmtoff);
}
At the moment this prints -25200, indicating that Los Angeles is 25200 seconds, or 420 minutes, or 7 hours west of Greenwich. But next week (actually tomorrow) the U.S goes off of DST, at which point this code will start printing -28800.
This isn't guaranteed to work, since the tm_gmtoff field is not portable. But I believe all versions of Linux will have it. (You might have to compile with -D_BSD_SOURCE or something, or refer to the field as __tm_gmtoff. But in my experience it tends to work by default, as plain tm_gmtoff.)
The other way is to go back and forth with gmtime and mktime, as described in Sam Varshavchik's answer.
Addendum: You asked about not using environment variables. There is a way, but unfortunately it's even less standard. There are BSD functions tzalloc and localtime_rz which do the job, but they do not exist on Linux. Here's how the code looks:
timezone_t tz = tzalloc("America/Los_Angeles");
if(tz == NULL) return 1;
time_t t = time(NULL);
struct tm tm, *tmp = localtime_rz(tz, &t, &tm);
printf("%ld\n", tmp->tm_gmtoff);
For me this prints -28800 (because PDT fell back to PST just a few minutes ago).
If you had it, you could also use localtime_rz along with mktime in Sam Varshavchik's answer. And of course Howard Hinnant's library is pretty obviously thread-safe, not requiring mucking with TZ at all.
EDIT (OP): The code for localtime_rz and tzalloc can be downloaded from https://www.iana.org/time-zones and works on Ubuntu 14.04.
You could use this free open source C++11/14 library to do it like this:
#include "chrono_io.h"
#include "tz.h"
#include <iostream>
int
main()
{
using namespace date;
using namespace std::chrono;
auto zt = make_zoned("America/Los_Angeles", system_clock::now());
std::cout << zt.get_info().offset << '\n';
}
This currently outputs:
-25200s
Or you could format it differently like this:
std::cout << make_time(zt.get_info().offset) << '\n';
which currently outputs:
-07:00:00
The factory function make_zoned creates a zoned_time using the IANA name "America/Los_Angeles" and the current time from std::chrono::system_clock. A zoned_time has a member getter to get the information about the timezone at that time. The information is a type called sys_info which contains all kinds of useful information, including the current UTC offset.
The UTC offset is stored as a std::chrono::seconds. The header "chrono_io.h" will format durations for streaming. Or the make_time utility can be used to format the duration into hh:mm:ss.
The program above is thread-safe. You don't have to worry about some other process changing TZ out from under you, or changing the current time zone of the computer in any other way. If you want information about the current time zone, that is available too, just use current_zone() in place of "America/Los_Angeles".
If you wanted to explore other times, that is just as easy. For example beginning at Nov/6/2016 at 2am local time:
auto zt = make_zoned("America/Los_Angeles", local_days{nov/6/2016} + 2h);
The output changes to:
-28800s
-08:00:00
More information about this library was presented at Cppcon 2016 and can be viewed here:
https://www.youtube.com/watch?v=Vwd3pduVGKY
Use gmtime(), first, to convert the current epoch time into UTC time, then use mktime() to recalculate the epoch time, then compare the result to the real epoch time.
gmtime() calculates the struct tm in UTC, while mktime() assumes that the struct tm represents the current local calendar time. So, by making this round-about calculation, you indirectly figure out the current timezone offset.
Note that mktime() can return an error if struct tm cannot be convert to epoch time, which will happen during certain transitions between standard time and alternate time. It's up to you to figure out what that means, in your case.
The recipe looks something like this:
time_t t = time(NULL);
struct tm *tmp = gmtime(&t);
time_t t2 = mktime(tmp);
int offset = t - t2;
See the documentation of these library functions for more information.
To use a specific time zone, either set the TZ environment variable, or you can try using localtime_rz as in Steve Summit's answer. As mentioned, beware that mktime can sometimes return -1 for unconvertible times.
I see a strange behavior while fetching the modification time of a file.
we have been calling _stat64 method to fetch the file modification in our project as following.
int my_win_stat( const char *path, struct _stati64 *buf)
{
if(_stati64( path, buf) == 0)
{
std::cout<<buf->st_mtime << std::endl; //I added to ensure if value is not changing elsewhere in the function.
}
...........
...........
}
When I convert the epoch time returned by st_mtime variable using epoch convertor, it shows 2:30 hrs ahead of current time set on my system.
When I call same API as following from different test project, I see the correct mtime (i.e. according to mtime of file shown by my system).
if (_stat64("D:\\engine_cost.frm", &buffer) == 0)
std::cout << buffer.st_mtime << std::endl;
Even I called GetFileTime() and converted FILETIME to epoch time with the help of this post. I get the correct time according to time set the system.
if (GetFileTime(hFile, &ftCreate, &ftAccess, &ftWrite))
{
ULARGE_INTEGER ull;
ull.LowPart = ftWrite.dwLowDateTime;
ull.HighPart = ftWrite.dwHighDateTime;
std::cout << (ull.QuadPart / 10000000ULL - 11644473600ULL);
}
What I am not able to figure out is why does the time mtime differ when called through my existing project?
What are the parameters that could affect the output of mtime ?
What else I could try to debug the problem further ?
Note
In VS2013, _stati64 is a macro which is replaced replaced by _stat64.
File system is NTFS on windows 7.
Unix time is really easy to deal with. It's the number of seconds since Jan 1, 1970 (i.e. 0 represents that specific date).
Now, what you are saying is that you are testing your time (mtime) with a 3rd party tool in your browser and expects that to give you the right answer. So... let's do a test, the following number is Sept 1, 2015 at 00:00:00 GMT.
1441065600
If you go to Epoch Converter and use that very value, does it give you the correct GMT? (if not, something is really wrong.) Then look at the local time value and see whether you get what you would expect for GMT midnight. (Note that I use GMT since Epoch Converter uses that abbreviation, but the correct abbreviation is UTC.)
It seems to me that it is very likely that your code extracts the correct time, but the epoch convertor fails on your computer for local time.
Note that you could just test in your C++ program with something like this:
std::cerr << ctime(&buf->st_mtime) << std::endl;
(just watch out as ctime() is not thread safe)
That will give you the data according to your locale on your computer at runtime.
To better control the date format, use strftime(). That function makes use of a tm structure so you have to first call gmtime or localtime.
An year later I ran into the similar problem but scenario is little different. But this time I understand why there was a +2:30Hrs of gap. I execute the C++ program through a perl script which intern sets the timezone 'GMT-3' and my machine had been in timezone 'GMT+5:30'. As a result there was a difference of '2:30Hrs'.
Why ? As Harry mentioned in this post
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.
I want to get the transition time for DST
Under Linux with giving time zone or TZ env.
My way is stupid, giving the start of the year and try every hour then check tm_isdst value of local time to get the transition time.
Is there some simple way to do this?
There is the source code in glibc, which you can browse here:
http://sourceware.org/git/?p=glibc.git;a=tree;f=timezone
Or you can use the timezone database here:
ftp://ftp.iana.org/tz/releases/tzdata2012c.tar.gz
Since you haven't given a particular timezone/location, I can't look up and give you the exact information for you.
You can also use boost_datetime.
#include <iostream>
#include <boost/date_time/local_time/local_time.hpp>
using namespace boost::local_time;
using namespace boost::posix_time;
int main()
{
tz_database tz_db;
tz_db.load_from_file("/path_to_boost/boost/libs/date_time/data/date_time_zonespec.csv");
time_zone_ptr zone = tz_db.time_zone_from_region("America/New_York");
ptime t1 = zone->dst_local_start_time(2013);
ptime t2 = zone->dst_local_end_time(2013);
std::cout << t1 << std::endl;
std::cout << t2 << std::endl;
}
Some related SO links:
c++ How to find the time in foreign country taking into account daylight saving?
How do you get the timezone (offset) for a location on a particular date?
But as RedX said earlier, politics may change time zones. So actually your original solution has the advantage of being automatically updated with the underlying OS. Also, you can improve your existing solution by using binary search.
i m new to c.I want to FTP to a system and get the timezone of that system.in c++
There is no way in the FTP standard to do this. You could try uploading a new (small) file and check its date-time as reported by FTP, compared to current local time.
New answer for old question.
Rationale for revisiting this: We have better tools now.
This free, open-source, portable library will get the current time zone setting in terms of the IANA time zone database. On Windows it will convert the Windows timezone into an IANA time zone. Fully documented.
Here's how you print out the name of the current time zone:
#include "tz.h"
#include <iostream>
int
main()
{
std::cout << date::current_zone()->name() << '\n';
}
For me this currently outputs:
America/New_York
You can convert a std::chrono::system_clock to a local time and print it out:
std::cout << date::make_zoned(date::current_zone(),
std::chrono::system_clock::now()) << '\n';
which just output for me:
2016-07-16 19:24:00.447015 EDT
See the github wiki for many more examples.
I'm having serious trouble with the function stat(). I have an application compiled under cygwin ond Windows 7 and the same app compiled with MSVC++ on Windows 7. The app contains the following code:
struct stat stb;
memset( &stb, 0, sizeof( stb ) );
stat( szPath, &stb );
cout << hex << uppercase << setw(8) << stb.st_mtime << endl;
szPath is a path to a file. The file does not get modified in any way by the app. The problem is, that i get different results for some files. For example:
cygwin version: 40216D72
MSVC++ version: 40217B82
The difference is always E10 = 3600 = 1 hour
By using google, i found this, which seems to be exactly the same issue i'm seeing. Is there a portable way how to fix this? I cannot use any WinAPI calls. The most simple and reliable solution is what i'm looking for, but if it needs to be complicated, so be it. Reliability and portability (win + linux) is the most important thing here.
To obtain both reliability and portability here (or in most situations of this sort where two platforms do different things with what should be the "same" code), you will probably need to use some form of target-dependent code, like:
#ifdef _MSC_VER
// do MSVC++-specific code
#else
// do Linux/Cygwin/generic code
#endif
You then ought to be able to use WinAPI calls in the _MSC_VER section, because that will only be compiled when you're using MSVC++
Apparently per http://support.microsoft.com/kb/190315 this is actually a FEATURE although it really seems like a bug to me. They say you can work around it by clearing "Automatically adjust clock for daylight saving changes" in the Date/Time Properties dialog box for the system clock.
If you have the date of the file, you can use the relative state of dst to determine if you need to make a one-hour adjustment yourself in MSVC only, but that's hacky as well.
Not sure about the functions you are using but I do know that Windows and Linux use the system clock differently. Windows stores local time (including DST) on the system clock. Linux (at least traditionally) stores GMT (or UTC to be precise) on the system clock. I don't if this applies to cygwin.
If a linux system shares hardware with windows it needs to be configured to use the system clock like windows or get messed-up every time windows adjusts DST.