Re: timezone_name?
In 011401ceaa8d$7b6acab0$72406010$@mcn.org, on 09/05/2013 at 04:13 PM, Charles Mills charl...@mcn.org said: EST5EDT Due to parsing ambiguity, that doesn't tell you when to switch. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
On Sun, Sep 8, 2013 at 5:52 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 011401ceaa8d$7b6acab0$72406010$@mcn.org, on 09/05/2013 at 04:13 PM, Charles Mills charl...@mcn.org said: EST5EDT Due to parsing ambiguity, that doesn't tell you when to switch. -- Shmuel (Seymour J.) Metz, SysProg and JOAT http://en.wikipedia.org/wiki/Tz_database does tell you when to switch. And when to add or subtract leap seconds. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
http://en.wikipedia.org/wiki/Tz_database does tell you when to switch. And when to add or subtract leap seconds. On Sun, Sep 8, 2013 at 5:52 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 011401ceaa8d$7b6acab0$72406010$@mcn.org, on 09/05/2013 at 04:13 PM, Charles Mills charl...@mcn.org said: EST5EDT Due to parsing ambiguity, that doesn't tell you when to switch. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
http://en.wikipedia.org/wiki/Tz_database Does tell you the offset, when to switch. And when to add or subtract leap seconds. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
On Sun, 8 Sep 2013 08:04:35 -0500, Mike Schwab wrote: http://en.wikipedia.org/wiki/Tz_database Does tell you the offset, when to switch. And when to add or subtract leap seconds. z/OS is the only OS of which I know that accommodates leap seconds in its hardware clock (are there others?) I believe (there's no documentation and IBM has rejected my RCF that it be provided; Peter Relson (IIRC) has suggested that I must appeal to common knowledge for the information) that STCKCONV, the IBM utility for converting historical (E)TOD values such as might appear in log files, is ignorant of the calendar of historical leap seconds. And I believe z/OS does not employ Tz_database for setting CVTLSO. Do other OSes employ the leap seconds part of the Tz_database, perhaps through NTP client? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
I'm not sure I understand Paul's last post. z/OS does keep the current leap-second count at hand. This value changes at most twice a year, at the end of June and at the end of December; and ample advance notice, at least six months' notice under BIPM's rules, is given of an impending increment or decrement. Consulting a real-time data base in these circumstances seems to me to be overkill. Why not update a static table? John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
In cajtoo5-bqbx01z2xwzf_z0eoc5nzua+5pxat6rep1oazzwc...@mail.gmail.com, on 09/08/2013 at 08:02 AM, Mike Schwab mike.a.sch...@gmail.com said: http://en.wikipedia.org/wiki/Tz_database does tell you when to switch. The Devil is in the details. The string EST5EDT doesn't have enough information to unambiguously indicate the country and zone. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
On Sun, 8 Sep 2013 16:22:53 -0400, John Gilmore wrote: I'm not sure I understand Paul's last post. z/OS does keep the current leap-second count at hand. This value changes at most twice a year, at the end of June and at the end of December; and ample advance notice, at least six months' notice under BIPM's rules, is given of an impending increment or decrement. I thought it was four months. Whatever. But it does not keep a record of the change history, necessary for converting archival timestamps, assuming they were recorded in (E)TOD format. Consulting a real-time data base in these circumstances seems to me to be overkill. Why not update a static table? Agreed. Consider the static table to be a cache of the data base, updated as necessary, which is seldom. In fact, I think ICANN and IERS supply only flat files, to be formatted as necessary. The multiplicity rises for civil time zones, but a static table in (virtual) memory, suitably indexed, may still be the right approach. UNIX likes to use filesystem directories as pseudo-KSDS indices. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
It is your thread, and I have no wish to hijack it. This will therefore be my last post for it. I chose Australian local times advisedly. They illustrate the differences between Daylight|Summer|Official times and Standard ones in the northern and southern hemispheres. You mentioned that you needed to revise your 'parsing' of such strings as 'AMT4AMST', and I perhaps interpreted this too literally. If you are always handing off such strings to someone else, you need not take any responsibility for 'errors' in them. If you are going to try to make sense of them, then you need to understand such differing conventions as those embodied in MSK, Moscow Standard Time MSD, Moscow Daylight Time WET, Western European Time WEST, Western European Summer Time EST, Eastern Standard Time (United States) EDT, Eastern Daylight Time (United States) I have been down this road; and great care must, for example, be taken to disentangle the 'S' for Summer and the 'S' for Standard, assuming always that you are not delegating the responsibility for doing so to someone else. Good luck! -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
No John, I was not accusing you of highjacking. But I'm not processing the name portions of the TZ string. I'm not going EDT! Aha! I know what that means... Here's the problem I am trying to solve: What goes in timezone_name? I'm currently sticking the first three characters of TZ or a string such as EST5EDT in timezone_name, and I know that's wrong. What *should* I be doing instead? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, September 06, 2013 4:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: timezone_name? It is your thread, and I have no wish to hijack it. This will therefore be my last post for it. I chose Australian local times advisedly. They illustrate the differences between Daylight|Summer|Official times and Standard ones in the northern and southern hemispheres. You mentioned that you needed to revise your 'parsing' of such strings as 'AMT4AMST', and I perhaps interpreted this too literally. If you are always handing off such strings to someone else, you need not take any responsibility for 'errors' in them. If you are going to try to make sense of them, then you need to understand such differing conventions as those embodied in MSK, Moscow Standard Time MSD, Moscow Daylight Time WET, Western European Time WEST, Western European Summer Time EST, Eastern Standard Time (United States) EDT, Eastern Daylight Time (United States) I have been down this road; and great care must, for example, be taken to disentangle the 'S' for Summer and the 'S' for Standard, assuming always that you are not delegating the responsibility for doing so to someone else. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
Charles Mills wrote: But I'm not processing the name portions of the TZ string. I'm not going EDT! Aha! I know what that means... Here's the problem I am trying to solve: What goes in timezone_name? One possible solution: use a standard time zone, say Greenwich and base your names on that zone + - your offset. Something like this: use 'Greenwich+2S' for +2 hours Standard Time, or 'Greenwich-5.5D' for -5.5 hours daylight saving and so on. While you're at it, just use 'Greenwich+?' or 'Greenwich-?' or simply 'local' for your local time. Or just Z+2S or Z-5.5D (Z for Zulu Time) This will work if you are not passing in/out the name from/to other people or software, ie, it will only work if you and your software are the only users of those names. Just a lame suggestion of course after watching this thread with interest. :-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
I haven't specifically looked, but IIRC, TZ can be specified as GMT plus/minus offset HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
On Fri, 6 Sep 2013 15:38:05 +, Staller, Allan wrote: I haven't specifically looked, but IIRC, TZ can be specified as GMT plus/minus offset Does the code then need to be changed semiannually? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
It can, but that was not the question. :-) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Friday, September 06, 2013 8:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: timezone_name? I haven't specifically looked, but IIRC, TZ can be specified as GMT plus/minus offset -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
In the OMVS profile we set timezone like this: TZ=CST6CDT5 -6 for Central Standard and -5 for Central Daylight. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, September 05, 2013 6:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: timezone_name? 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. I am reading the notes following, for example, localtime() but I don't know what exactly to make of them. 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? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
On Fri, Sep 6, 2013 at 8:47 AM, Charles Mills charl...@mcn.org wrote: I'm currently sticking the first three characters of TZ or a string such as EST5EDT in timezone_name, and I know that's wrong. What *should* I be doing instead? Charles You should use the portion in front of the offset digits (5,+5, -2, etc) during standard time (winter) and use the portion after the offset during daylight savings time (summer). Lengths may vary. Date ranges could be specified in the TZ variable. http://en.wikipedia.org/wiki/List_of_tz_database_time_zones has a nice list and a link to a tz database file. -- Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
Mike Schwab's point is well made. Some of these values are three-character ones, some of them are four-character ones, and five-character ones are obviously in the womb of time. A parse that deals swith this variability is, finally, trivial; but the issue should not be ignored. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
The specs seem to indicate it may be any number of characters. http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html Five-character time zones are already here. http://www.timeanddate.com/library/abbreviations/timezones/atlantic/azost.ht ml It appears you strip characters until you get to a non-alpha character. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, September 06, 2013 7:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: timezone_name? Mike Schwab's point is well made. Some of these values are three-character ones, some of them are four-character ones, and five-character ones are obviously in the womb of time. A parse that deals swith this variability is, finally, trivial; but the issue should not be ignored. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
If you are thinking in international rather than local American terms some timezone names are problematic/ambiguous. An example. Australia has three time zones: o AEST, Australian Eastern Standard Time, which becomes AEDT, Australian Eastern Daylight Time for part of the year, with conventions reversed from those of the Northern Hemisphere; o ACST, Australian Central Standard Time, and ACDT, Australian Central Daylight Time; and o AWST, Australian Western Standard Time, without an AWDT. So far, so good; but the 'A' prefix is fairly recent and not always used; and when it is omitted EST, EDT, CST, and CDT are internationally ambiguous. You could resolve such ambiguities---There are many of them---if you had an ISO country code at hand too. Do you? John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
You could resolve such ambiguities---There are many of them---if you had an ISO country code at hand too. Do you? Does the software at run time? I have not rooted around. Possibly -- probably at some sites yes, and at some sites no, they didn't set it (not unlike TZ and _TZ!). The one thing I am sure I have is a TZ value, either pre-existing, or passed to me as a character string that I then use to set TZ. I guess the software is not in the business of mind-reading people who use incorrect or obsolete time zone abbreviations. GIGO and all that. If they tell me EST and it's really AEST, well, no my fault, mon. strftime() %Z will probably report EST. GIGO. I see here http://www.timeanddate.com/library/abbreviations/timezones/ that AMT means +4 in Armenia and -4 in the Amazon. But does it matter to my software? If a customer specifies TZ=AMT4AMST won't localtime() work correctly, adjusting UTC by 3 or 4 hours on the assumption that he is in Armenia (and not be confused by the possibility he is actually in the Amazon)? I hope not to have this thread get into a whole digression on the vagaries of local time in general. My real questions are - what *sort* of value is supposed to be in timezone_name? Something like EST, or, for example, something like Eastern Standard Time, or ... ? - assuming e.g. EST is what is supposed to be in timezone_name, what is the best way of getting it from TZ to timezone_name? I'm going to start taking after Gil. I'm going to start signing my posts I hate local time. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Thursday, September 05, 2013 4:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: timezone_name? If you are thinking in international rather than local American terms some timezone names are problematic/ambiguous. An example. Australia has three time zones: o AEST, Australian Eastern Standard Time, which becomes AEDT, Australian Eastern Daylight Time for part of the year, with conventions reversed from those of the Northern Hemisphere; o ACST, Australian Central Standard Time, and ACDT, Australian Central Daylight Time; and o AWST, Australian Western Standard Time, without an AWDT. So far, so good; but the 'A' prefix is fairly recent and not always used; and when it is omitted EST, EDT, CST, and CDT are internationally ambiguous. You could resolve such ambiguities---There are many of them---if you had an ISO country code at hand too. Do you? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
On Thu, 5 Sep 2013 16:13:07 -0700, Charles Mills wrote:
2. Does setting timezone_name to EST or PDT make sense? Is EST or PDT an
appropriate sort of setting?
To be POSIXly correct, you should follow:
Title: z/OS V1R13.0 XL C/C++ Programming Guide
Document Number: SC09-4765-12
8.4.1 Using the TZ or _TZ environment variable to specify time zone
...
The TZ or _TZ environment variable has the following format.
||
| TZ=standardHH[:MM[:SS]] |
| [daylight[HH[:MM[:SS:]]] |
| [,startdate[/starttime],enddate[/endtime]]] |
||
||
Neither that nor POSIX gives an example in the glory of its full complexity.
But in, e.g.:
http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
EST+5EDT,M4.1.0/2,M10.5.0/2
But I prefer (and shall surely be castigated here for) the convention prevalent
on most open systems (opener, that is, than z/OS):
510 $ TZ=Australia/Canberra date; TZ=America/New_York date
Fri Sep 6 13:51:17 EST 2013
Thu Sep 5 23:51:17 EDT 2013
(Yes, note the E?T ambiguity.)
This even gives correct results for 2006 and earlier, which the POSIX
convention, adhered to by z/OS can not. (It's compatible; the POSIX
format is still supported.)
3. Is setenv() the most reasonable way to set timezone_name?
I believe I've used tzset():
int showtz ( char *tz ) {
putenv( tz );
if ( 0 ) tzset(); /* Not needed for strftime. */
return( showit( tz ) ); }
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
