Date-time conversions are messy. Attempts to treat them expose ambiguities that are otherwise mostly ignored.
Implicit in Chuck's original post is that he also has a date available. He needs a 4tuple: o date, o time, o location, specified as a latitude-longitude pair, and o identity, UTC|xDT The terminology "Daylight Saving[s]" time has disappeared from official use. It is <zone> Daylight Time, as in 'Eastern Daylight Time' in the United States, now. Elsewhere it may be "Summer Time", "Official Time", etc., etc. Note also that in the Southern Hemisphere, e.g., in Australia, summer and winter are reversed, with a small but important consequence for the calculation of correction factors. In general, date and time values are inseparable. The international date line exists and cannot be wished away. You will need do your conversions on a date-time value, not on a time value alone. Note also, and continuing with an Australian example, that three-character time-zone names are not unique. There is an Australian Eastern Standard Time, AEST, as well as a United Statesian Eastern Standards Time, UEST. Again, time-zone UTC offsets are not in general integers. The Australian Cocos Islands Time Zone is UTC+6.30. Skip Robinson is clearly right. A table-driven solution is ineluctable. You can get help, crucial help, from the IANA database, but in my experience it is never usable directly. You will need to extract the relevant data it contains, putting them into your own tables, which you will need to regenerate in at least quasi-automated fashion every time the IANA database is updated. It is common to grossly underestimate the complexity of date-time calculations, probably because they are usually botched without recognizing that they are being botched. 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
