My point was that there is no useful 'algorithm' for doing the conversion. You have to take both geography and politics into account. I.e. a table. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected]
From: Paul Gilmartin <[email protected]> To: [email protected], Date: 06/27/2014 04:21 PM Subject: Re: Local Time conversion to/from UTC Time Sent by: IBM Mainframe Discussion List <[email protected]> On Fri, 27 Jun 2014 15:21:54 -0400, John Gilmore wrote: >Do you need a point solution, i.e., one for a particular longitude and >latitude? Or dxo you need a general one that is parametric in >location? > And, likewise, does he need a solution for a particular time, or a general one that is parametric in time. Note that for two hours each Fall, local times are ambiguous where Daylight saving ime is observed. On Fri, 27 Jun 2014 16:55:00 -0600, Mark Post wrote: >>>> On 6/27/2014 at 06:37 PM, Skip Robinson wrote: >> I think your solution will have to be table driven with >> an entry for every country and for every U.S. state. > (Cartesian product with every legislative change in time zone boundaries and Daylight Saving conventions.) >Such a table already exists. >http://www.iana.org/time-zones > Why does IBM for z/OS and VM refuse to embrace this solution otherwise used by all other UNIX-like systems I know? Perfidious NIH. On Fri, 27 Jun 2014 11:06:25 -0700, Hardee, Chuck wrote: > >Note, implementations using CONVTOD and TODCONV won't work for my needs. > How can you conclude that, given that IBM declines to provide adequate documentation for CONVTOD and STCKCONV? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
