>>>> What does the "I" in IBM stand for? Paul,
My apologies about the earlier clarification of "I". Since OP asked for a specific timezone (EST to be precise), I am not sure as to what you are trying to bring in "International" into the discussion. Thanks, Kolusu From: Sri h Kolusu/Silicon Valley/IBM@IBMUS To: [email protected] Date: 02/04/2016 11:40 AM Subject: Re: DFSORT - SMF Records - GMT To EST Sent by: IBM Mainframe Discussion List <[email protected]> >>Hmmm... Your example covers 4 time zones, all in the contiguous USA. And I don't see that it accounts for the 2007 change. Paul, What 2007 change don't you see accounted for? The first IFTHEN=(WHEN=INIT calculates the begin and end dates of DST based off NIST rules and there is a check to subtract 1 from the offset. So please check once again. >>> Alaska and Hawaii add two more. And Hawaii and Arizona don't observe Daylight saving time. Not Samoa? USA only? My example just shows the prominent time zones . If the user wants more time zones, all he needs to do is add more time zones in the CHANGE command. It is simple change. You can add any number of time zones you want. >> What does the "I" in IBM stand for? If you are referring to the "I" in the text about the training , it refers to myself as I will be the one providing the training. >>I wonder whether the IANA database could be extracted and formatted as a canned procedure for DFSORT? You can extract the database and generate DFSORT symbols that can be used in the Time zone command >>> Your example shows me that DFSORT is not the best tool for the job; it can be done, but like Samuel Johnson's dog, it is surprising that it is > done at all. Thanks for the opinion but I would really appreciate if you can stop the comparison for DFSORT. >>> STCKCONV and CONVTOD are hot the answer; their capabilities are pathetic. For the record, DFSORT does use STCKCONV. If the time is in TOD format then you can use DFSORT TC1 format to convert it to readable format Example: 099,8,TC1,EDIT=(TT:TT:TT), $ TOD TIME The 8 bytes of an input clock value, in the basic time-of-day (TOD) format, is converted to a Z'hhmmss' value. The STCKCONV macro is used to do the conversion. >>I mentioned Java. Not realistic. It produces correct answers, but performance is abysmal. DFSORT does produces the correct answers provided you list out all the timezones you want Thanks, Kolusu IBM Mainframe Discussion List <[email protected]> wrote on 02/04/2016 11:15:34 AM: > From: Paul Gilmartin <[email protected]> > To: [email protected] > Date: 02/04/2016 11:16 AM > Subject: Re: DFSORT - SMF Records - GMT To EST > Sent by: IBM Mainframe Discussion List <[email protected]> > > On Thu, 4 Feb 2016 10:37:53 -0700, Sri h Kolusu wrote: > > >>>And Ravi has clarified that he wants the technique to be aware of > >Daylight Saving Time. And I recall the rules in the U.S. changed in 2006. > > And more > >recently in the Nation of Samoa. > >Sigh. DFSORT (and DB2) ought to be savvy to: > > https://www.iana.org/time-zones > > > >(Java knows this. Linux knows this. ... ) > > > >Paul, > > > > I am not sure as to what your gripe is but it is really sad to see you > >complain on every bit of DFSORT when you don't realize the full potential > >of its capability. May be it is time for your shop to pay for a training > >class on DFSORT and I will be more than happy to show you its full > >potential. Here is a small sample Job that calculates the Day light > >savings begin date and end date and then adjust the offset according to > >them and as well as gives the option for the user to pick whatever time > >zone he wants these calculations to be based on. If the user does not pass > >a time zone then it defaults to PST. > > > >And just for your record, according to "National Institute of Standards > >and Technology" the DST rules are changed in 2007. > > > >http://www.nist.gov/pml/div688/dst.cfm > > > Thanks for the correction. I was close. And the important point is that > today's rules don't cover even the last several years, within the relevance > of DB2 (though perhaps not SMF) data. > > Your example shows me that DFSORT is not the best tool for the job; > it can be done, but like Samuel Johnson's dog, it is surprising that it is > done at all. > > Time conversion functions should be modular, outside DFSORT, and > available to all applications. > > Hmmm... Your example covers 4 time zones, all in the contiguous USA. > And I don't see that it accounts for the 2007 change. Alaska and Hawaii > add two more. And Hawaii and Arizona don't observe Daylight saving > time. > > Not Samoa? USA only? What does the "I" in IBM stand for? > > I wonder whether the IANA database could be extracted and formatted > as a canned procedure for DFSORT? > > Again, I don't believe DFSORT (the Swiss Army Knife utility, probably > Turing-complete) is the proper venue in which to solve this problem, > but z/OS ought to provide a solution. STCKCONV and CONVTOD are > hot the answer; their capabilities are pathetic. > > I mentioned Java. Not realistic. It produces correct answers, but > performance is abysmal. > > Thanks again, > gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
