localtime is not thread-safe. Even calling localtime with different values for printing like
printf( "Zone1: %s Zone2: %s\n", localtime(seconds1), localtime(seconds2); will print the same value for both. http://pubs.opengroup.org/onlinepubs/007904875/functions/localtime_r.html You must store off the result before the next call as it reuses the string. On Tue, Nov 19, 2013 at 2:32 PM, website reader <[email protected]>wrote: > While changing from Unix epoch time, to calendar time, using the > localtime() function, this works great when you expect the calendar to be > correct for your local timezone, as the computer determines it to be. > > However I have been trying to change from epoch time to the tm structure in > different timezones, and have occasionally hit with failure (defaulting > back to the local timezone) in about 1 in 200 attempts. > > My code reads: > > timespec unix_time = { 1384899797,0}; // recent example > std:string zone("EST"); > struct tm new_calendar; > time_t* current_secs = &unix_time.tv_sec; > setenv("TZ", const_cast<char*>(zone.c_str)),1); > new_calender = *localtime(current_secs); > > However I am running 7 or 8 threads and they are calling this function too > so collisions to this localtime() library call might be possible. > > Is there anyway to have a guaranteed way to do this? Hide this call inside > a Posix mutex? > > Will it be necessary to make atomic calls to this routine to insure correct > conversion? > > Randall > > p.s. I have noticed that apparently the system is setting the TZ variable > back to the local time zone or something is glitching during this time > conversion. > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
