I try to avoid what Quine called mathematosis in my posts, but I lapsed: UTC offsets are not in general integers
is mathematically correct; but, as Bill Fairchild points out, it conveys the wrong impression, a suggestion that most of them are not integers, to non-mathematicians. My point was that since a non-trivial number of them are not integers, an integer data type, which I have encountered too freq, is a bad choice for On 6/29/14, DASDBILL2 <[email protected]> wrote: >>time-zone UTC offsets are not in general integers. The Australian Cocos >> Islands Time Zone is UTC+6.30. > > Most places are an integral number of hours + or - from Greenwhich. There > are a few that are a half hour off from an integral number of hours > difference. And at last one whole country, Nepal, is 4 hours 45 minutes > greater than Greenwich. Here is a list of most large cities: > http://www.timeanddate.com/worldclock/ > > Here is a view of the whole world's time zones in one complex picture: > http://www.timeanddate.com/time/map/ > > Bill Fairchild, Senior Software Engineer > ASG Software Services > Naples, FL > > ----- Original Message ----- > > From: "John Gilmore" <[email protected]> > To: [email protected] > Sent: Saturday, June 28, 2014 8:53:58 AM > Subject: Re: Local Time conversion to/from UTC Time > > 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 [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 > -- John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
