On Oct 8, 8:27?pm, "Nicholas Bastin" <[EMAIL PROTECTED]> wrote: > On 10/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > What do you mean by "the military" and why do you think they're > > > authoritative on the topic of timezones? > > > Because they publish maps? > > I'm not sure what this has to do with it.
Maybe you've never had to navigate? > > > > but as far as I know they don't define timezones. > > > Ok, maybe they don't define them. But they get them from somewhere > > and the zones are labeled A-Z (don't ask which letter isn't used). > > Zone Z is equivalent to GMT and the time is refered to as Zulu time. > > They get them from NATO. NGO's outside of NATO do not use NATO time > zones for describing time data, mostly because NATO doesn't care about > daylight savings time. Works fine for the military, but not so well > for your civilian users. > > > That's 25 zones, not 400. Under that system there are no half-hour > > offset zones, no zones based on sunset and no lunatic GMT+13 zones. > > Yes, but lucky for us, we live in the real world, so we have to deal > with 400 time zones. The reality is that people LIVE in those > 'lunatic' time zones, and software needs to address that. WHY must we accomodate the ignorant? Why not cut them off from the Internet until they get their act together? Don't people get mad at Microsoft for breaking standards? People like you are to blame for accomodating broken standards. "Oh, no, we can't afford to lose those three potential customers who live on an island in Kiribati!" > > If I schedule a meeting with someone in Indiana, and I'm in Ohio, > they're in the same military time zone, but they don't observe > daylight savings time, so in fact our times are different. Users > probably want our applications to handle these problems. Isn't that what they call a "locale"? > > > > Since timezones (obviously) > > > contain more information than just the GMT offset > > > Of course. But the GMT offset could be used to filter his list > > of 400 choices, couldn't it? > > Sortof. First, your user has to understand what GMT is, And you start that education by learning the 25 timezones. Then when you understand that, you can then learn about locales. > so that's > already going to cause problems. Secondly, you need to handle time > zones which drift from different GMT offsets depending on the time of > year. It helps to know what you're drifting from. > At the very least your algorithm needs to be greedy. How good an algorithm do you think the OP will come up with if he doesn't understand why his list has 400 items or has any clue how to reduce it? > > > Agreed. But if someone gave me a list of 400 choices, I would look > > for some way to reduce the list to a manageable choice. Isn't that > > what the OP wants? > > > Why not teach him the truth, starting from the top level? Shouldn't > > you teach him to fish rather than just give him one? > > Because the truth is that there are upwards of 400 different time > zones, Locales. > accounting for local custom and law. The military can > conveniently ignore that, but we as application writers cannot. But you can safely ignore the basis of the 400 locales? > > There is no central authority which defines global time zones. The > functional definition of a time zone is merely a geographical area of > the earth that has adopted the same local time rules. So, you can live your life with functional definations, never bothering to learn any theory? Is code monkey all you aspire to? > > -- > Nick -- http://mail.python.org/mailman/listinfo/python-list
