On Thu, 5 Sep 2013 16:13:07 -0700, Charles Mills wrote: >I'm looking at my C++ code. I wrote it, but I wrote it before I understood >as much (?) as I do now, and before GSK surprised me and made me run >POSIX(ON). > >Background: the code runs on many different systems and customers set their >machines up the way they set them up. The code uses localtime() and also >occasionally strftime() with various format specifiers. I think I have a >pretty good handle on the function of the TZ environment variable. > >But I see code that sets the environment variable timezone_name to a string >such as EST or PDT. I don't know exactly why the code is there.
Is the code you are referring to using setenv to set timezone_name? Maybe whoever wrote that code didn't know what they were doing. That might be a possibility. > >I am reading the notes following, for example, localtime() but I don't know >what exactly to make of them. Are you referring to this description of localtime in the XL C/C++ Run-Time Library Reference? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/EDCLB1C0/3.561.4 where it says "The ctime(), localtime(), and mktime() functions now return Coordinated Universal Time (UTC) unless customized locale information is made available, which includes setting the timezone_name variable." Maybe it doesn't mean an environment variable. Further down that page it refers to "Customizing a time zone" in the XL C/C++ Programming Guide. That page: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CBCPG1C0/8.4 That page refers to "LC_TOD category" which is a link to this page: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CBCPG1C0/8.2.3.7 which describes variables timezone_name and daylight_time and others, but they are not environment variables, they are used to customize locales. The POSIX locale was built from CEE.SCEELOCX(EDC$POSX), which does not include a definition of LC_TOD, and I'm not sure if it would be a good idea to change this. But locale definitions for LC_TOD are probably the only place where a variable named timezone_name would be set. > >1. I assume I do need to set timezone_name or localtime() may not function >correctly, and certainly not strftime %Z. Is that assumption correct? > >2. Does setting timezone_name to EST or PDT make sense? Is EST or PDT an >appropriate sort of setting? > >3. Is setenv() the most reasonable way to set timezone_name? I can see that >my parsing of strings such as "EST5EDT" into a timezone_name is inadequate, >but before I re-write it I wanted to see if it was really necessary. Is >there a better way to do things? Is there a library function that will parse >TZ into among other things timezone_name, so I don't have to re-invent the >wheel, possibly badly? > It's probably best to forget about timezone_name. Bill ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
