[barmar]

I think I found where I got it from. I just googled "time zone menu html", and the menu in the #2 hit looks exactly like what I have: http://michaelapprov...wn-select-list. So it's Michael Khaili's fault.

 MolvaM, on 2012-August-29, 16:24, said:

- The time zone alternatives are inadequate. The GMT+2 alternatives are particularly interesting: South africa and Kaliningrad!!! I suggest the following:
GMT+1: Amsterdam, Barcelona, Belgrade, Berlin, Budapest, Copenhagen, Frankfurt, Pairs, etc
GMT+2: Istanbul, Ankara, Athens, Talinn, Helsinki, Jerusalem, Baghdad, Amman, Beirut, Sofia, Nairobi, Bucharest, Kiev

I don't really want so many cities -- the menu will stretch all the way across the screen. 3-4 representative cities should be enough -- most people know what zone they're in or what major cities are in the same zone.

I'll look around for another list.

[jallerton]

 RMB1, on 2012-August-30, 16:27, said:

Sorry that this is getting off topic. I think you would need to split time zones into places that use daylight saving in the (northern hemisphere) summer, those that use daylight saving in the southern hemisphere summer, and places with no daylight saving.

It's actually slightly more complicated than that as there are some countries/regions of countries which put their clocks forward and/or back on different dates than other countries/regions of countries in the same hemisphere in the same basic time zone.

I don't think that this subject if off topic. Vugraph automation is attempting to automate much of Roland's work, and Roland's knowledge of world time zones is second to none.

 barmar, on 2012-August-31, 09:52, said:

I don't remember where I got it. Someone posted somewhere "this is what I use for selecting time zones", and I just copied it.

I guess you haven't looked at the actual menu, since it doesn't have Boise or Denver. The US timezones don't bother mentioning any specific US cities, they just name the zones. E.g. -6 says "Central Time (US & Canada), Mexico City".

As far as DST goes, there's a separate checkbox on the form for that. If you're in a location that doesn't use it, don't check it.

Taking your example, Mexico City and Dallas are in the same basic time zone (GMT-6 in Winter) and both use "daylight saving time". However, these two places do not always share the same time as they put the clocks forward (and back) on different dates.

There are also some events which take place on the Saturday and Sunday of a weekend in which the clocks go forward or back.

I suspect that you need more than a checkbox to deal with this.

[barmar]

 jallerton, on 2012-August-31, 10:40, said:

It's actually slightly more complicated than that as there are some countries/regions of countries which put their clocks forward and/or back on different dates than other countries/regions of countries in the same hemisphere in the same basic time zone.

My script doesn't depend on knowing precisely when the clock changes. It compares the current timezone offset to the offsets on January 1 and July 1. If it's the same as January, you're in standard/winter time, if it's the same as July you're in daylight/summer time. And this is only done to set the default for the DST checkbox. If DST is not currently in effect, but will be when the event takes place (or vice versa), you check/uncheck the box.

Quote

Taking your example, Mexico City and Dallas are in the same basic time zone (GMT-6 in Winter) and both use "daylight saving time". However, these two places do not always share the same time as they put the clocks forward (and back) on different dates.

I don't think that matters for this application. Remember, this is INPUT from the user -- he's telling us, when creating the event, whether the times he's entering are in standard or daylight time. We aren't going to do any automatic adjustments based on when the country's clock changes.

Quote

There are also some events which take place on the Saturday and Sunday of a weekend in which the clocks go forward or back.

I suspect that you need more than a checkbox to deal with this.

Yes, that's the one case I don't handle, since a separate timezone entry for each round seemed like overkill. In the rare case that this happens, the user entering the info will need to adjust the times of one of the days by hand.

Note that none of this has anything to do with how the vugraph schedule page displays, that's still always in the viewer's timezone. The database stores everything in our server's timezone, and the timezone menu is just used during entry to convert to that.

[barmar]

I've updated the timezone menu to this:

• GMT -12:00: Eniwetok, Kwajalein
  
• GMT -11:00: Midway Island, Samoa
  
• GMT -10:00: Hawaii
  
• GMT -9:00: Alaska
  
• GMT -8:00: PT (US/Canada), Tijuana
  
• GMT -7:00: MT (US/Canada), Chihuahua, Mazatlan
  
• GMT -6:00: CT (US/Canada), Mexico City
  
• GMT -5:00: ET (US/Canada), Bogota, Lima
  
• GMT -4:00: Atlantic Time (Canada), Caracas, La Paz
  
• GMT -3:30: Newfoundland
  
• GMT -3:00: Brazil, Buenos Aires, Georgetown
  
• GMT -2:00: Mid-Atlantic
  
• GMT -1:00: Azores, Cape Verde Islands
  
• GMT: WET, London, Lisbon, Casablanca
  
• GMT +1:00: CET, Brussels, Copenhagen, Madrid, Paris
  
• GMT +2:00: EET, Athens, Istanbul, Helsinki, S. Africa
  
• GMT +3:00: Baghdad, Riyadh, Moscow, St. Petersburg
  
• GMT +3:30: Tehran
  
• GMT +4:00: Abu Dhabi, Muscat, Baku, Tbilisi
  
• GMT +4:30: Kabul
  
• GMT +5:00: Ekaterinburg, Islamabad, Karachi, Tashkent
  
• GMT +5:30: Chennai, Kolkata, Mumbai, New Delhi
  
• GMT +5:45: Kathmandu
  
• GMT +6:00: Almaty, Dhaka, Colombo, Novosibirsk
  
• GMT +6:30: Rangoon
  
• GMT +7:00: Bangkok, Hanoi, Jakarta
  
• GMT +8:00: Beijing, Perth, Singapore, Hong Kong
  
• GMT +9:00: Tokyo, Seoul, Osaka, Sapporo, Yakutsk
  
• GMT +9:30: Adelaide, Darwin
  
• GMT +10:00: Eastern Australia, Guam, Vladivostok
  
• GMT +11:00: Magadan, Solomon Islands, New Caledonia
  
• GMT +12:00: Auckland, Wellington, Fiji, Kamchatka

[paulg]

 barmar, on 2012-August-31, 17:11, said:

• GMT: WET, London, Lisbon, Casablanca

Highly appropriate as we've had the wettest summer in one hundred years. Scotland, of course, should WET++.

[jallerton]

 barmar, on 2012-August-31, 17:11, said:

I've updated the timezone menu to this:

• GMT -12:00: Eniwetok, Kwajalein
  
• GMT -11:00: Midway Island, Samoa
  
• GMT -10:00: Hawaii
  
• GMT -9:00: Alaska
  
• GMT -8:00: PT (US/Canada), Tijuana
  
• GMT -7:00: MT (US/Canada), Chihuahua, Mazatlan
  
• GMT -6:00: CT (US/Canada), Mexico City
  
• GMT -5:00: ET (US/Canada), Bogota, Lima
  
• GMT -4:00: Atlantic Time (Canada), Caracas, La Paz
  
• GMT -3:30: Newfoundland
  
• GMT -3:00: Brazil, Buenos Aires, Georgetown
  
• GMT -2:00: Mid-Atlantic
  
• GMT -1:00: Azores, Cape Verde Islands
  
• GMT: WET, London, Lisbon, Casablanca
  
• GMT +1:00: CET, Brussels, Copenhagen, Madrid, Paris
  
• GMT +2:00: EET, Athens, Istanbul, Helsinki, S. Africa
  
• GMT +3:00: Baghdad, Riyadh, Moscow, St. Petersburg
  
• GMT +3:30: Tehran
  
• GMT +4:00: Abu Dhabi, Muscat, Baku, Tbilisi
  
• GMT +4:30: Kabul
  
• GMT +5:00: Ekaterinburg, Islamabad, Karachi, Tashkent
  
• GMT +5:30: Chennai, Kolkata, Mumbai, New Delhi
  
• GMT +5:45: Kathmandu
  
• GMT +6:00: Almaty, Dhaka, Colombo, Novosibirsk
  
• GMT +6:30: Rangoon
  
• GMT +7:00: Bangkok, Hanoi, Jakarta
  
• GMT +8:00: Beijing, Perth, Singapore, Hong Kong
  
• GMT +9:00: Tokyo, Seoul, Osaka, Sapporo, Yakutsk
  
• GMT +9:30: Adelaide, Darwin
  
• GMT +10:00: Eastern Australia, Guam, Vladivostok
  
• GMT +11:00: Magadan, Solomon Islands, New Caledonia
  
• GMT +12:00: Auckland, Wellington, Fiji, Kamchatka

Thanks for the updated list. Unfortunately it does seem to contain quite a few errors; perhaps you are using an old source.

For example:

Sri Lanka (including Colombo) uses Indian Standard Time (GMT+5:30).

Many of the times in Russia are an hour ahead of the times you list (e.g Moscow is GMT+4 all year round). It may be possible to describe Moscow as technically GMT+3 with permanent "daylight saving", but it might not be obvious to the organiser of a Russian event to check the "daylight saving" box in January when there is a metre of snow outside.

Samoa is now GMT+13. This is not the same as GMT-11. If Samoa hosts a BBO event, you don't want the commentators turning up at the right time but on the wrong day!

[Walddk]

 jallerton, on 2012-September-01, 03:33, said:

Thanks for the updated list. Unfortunately it does seem to contain quite a few errors; perhaps you are using an old source.

For example:

Sri Lanka (including Colombo) uses Indian Standard Time (GMT+5:30).

Many of the times in Russia are an hour ahead of the times you list (e.g Moscow is GMT+4 all year round). It may be possible to describe Moscow as technically GMT+3 with permanent "daylight saving", but it might not be obvious to the organiser of a Russian event to check the "daylight saving" box in January when there is a metre of snow outside.

Samoa is now GMT+13. This is not the same as GMT-11. If Samoa hosts a BBO event, you don't want the commentators turning up at the right time but on the wrong day!

The problem arises because most organisers don't know what GMT = Greenwich Mean Time (or UTC/Zulu) is. They think London = GMT all year round, although it only applies six months a year. Strange you could argue, as Greenwich is located in London, but that's how it is, and here is where the 'human touch' comes in. If nothing else, my job for 10 years made me an expert on time zones, and I was therefore able to step in and correct 'obvious' errors before they hit the vugraph schedule web page.

Then I would be able to approach potential commentators with correct session times. The automation procedure makes things uncertain and was the main reason for my departure. I made that point in several emails to the management, but I was alone when I expressed my concern. When one is not comfortable with a new formula, it is time to call it a day.

[barmar]

 jallerton, on 2012-September-01, 03:33, said:

Thanks for the updated list. Unfortunately it does seem to contain quite a few errors; perhaps you are using an old source.

It's clearly newer than the original one I used -- several cities had changed names, and this one had the new names (e.g. Mumbai instead of Bombay). But apparently it's not up-to-date on the timezone laws.

Quote

Many of the times in Russia are an hour ahead of the times you list (e.g Moscow is GMT+4 all year round). It may be possible to describe Moscow as technically GMT+3 with permanent "daylight saving", but it might not be obvious to the organiser of a Russian event to check the "daylight saving" box in January when there is a metre of snow outside.

Looks like this was just changed last year, according to Wikipedia. It also says:

Quote

The section of European Russia (the portion of Russia west of the Ural Mountains), which contains the city of Moscow, uses Moscow Time. In Kaliningrad Oblast, UTC+3 is used.

My Russian geography knowledge is nonexistent -- if you can help me out and tell me which specifically need to be fixed, I'll take care of it.

[jallerton]

OK, here is my suggested list of corrections (this assumes that you are only prepared to have one line for even the more popular time zones and do not wish to split time zones which use "daylight saving" from those which don't).

• GMT -12:00: Eniwetok, Kwajalein
  
• GMT -11:00: Midway Island, Samoa
  
• GMT -10:00: Hawaii
  
• GMT -9:00: Alaska
  
• GMT -8:00: PT (US/Canada), Tijuana
  
• GMT -7:00: MT (US/Canada), Chihuahua, Mazatlan
  
• GMT -6:00: CT (US/Canada), Mexico City
  
• GMT -5:00: ET (US/Canada), Bogota, Lima
  
• GMT -4:30: Caracas
  
• GMT -4:00: Atlantic Time (Canada), Caracas, La Paz, Georgetown, Asuncion
  
• GMT -3:30: Newfoundland
  
• GMT -3:00: BrazilBrasilia, Buenos Aires, Georgetown, Montevideo, Greenland
  
• GMT -2:00: Mid-Atlantic
  
• GMT -1:00: Azores, Cape Verde Islands
  
• GMT: WET, London, Lisbon, Reykjavik, Monrovia, Casablanca,
  
• GMT +1:00: CET, Brussels, Copenhagen, Madrid, Paris, West Central Africa
  
• GMT +2:00: EET, Athens, Istanbul, Helsinki, South Africa
  
• GMT +3:00: Baghdad, Riyadh, Nairobi, KaliningradMoscow, St. Petersburg
  
• GMT +3:30: Tehran
  
• GMT +4:00: Abu Dhabi, Muscat, Moscow, St. Petersburg, Baku, Tbilisi
  
• GMT +4:30: Kabul
  
• GMT +5:00: Ekaterinburg, Islamabad, Karachi, Tashkent
  
• GMT +5:30: Chennai, Kolkata, Mumbai, New Delhi, Colombo
  
• GMT +5:45: Kathmandu
  
• GMT +6:00: Almaty, Astana, Dhaka, Colombo, Ekaterinburg Novosibirsk
  
• GMT +6:30: Rangoon
  
• GMT +7:00: Bangkok, Hanoi, Jakarta, Novosibirsk
  
• GMT +8:00: Beijing, Perth, Singapore, Hong Kong
  
• GMT +9:00: Tokyo, Seoul, Osaka, Sapporo, Irkutsk Yakutsk
  
• GMT +9:30: Adelaide, Darwin
  
• GMT +10:00: Sydney, Brisbane, Guam, Yakutsk Vladivostok
  
• GMT +11:00: Magadan, Solomon Islands, New Caledonia, Vladivostok
  
• GMT +12:00: Auckland, Wellington, Fiji, Kamchatka, Magadan
  
• GMT +13:00: Samoa, Nuku'alofa

[barmar]

Thanks, I've made these changes. If you want to see what the form looks like, to go here.

[mycroft]

Ah, you're using the Microsoft-style zones. I can see that. The IANA standard (which linux, et al. uses) is Continent/City, using the tz_database. It's - barking huge (Wikipaedia URLs). And unless you have a way to navigate it (there's almost certainly php code out there; probably others), a bit of a pain for your users, and probably overkill for the setup, as the requester will be smart enough to do the Summer Time thinking for you. Not so sure on the commentator's end, though, but you don't seem to be having much issues with "this page shows everything in your time" on the VuGraph web page, so I guess that's worked out too.

As long as something works. I'm not 100% sure how I'd set up the upcoming Phoenix Regional or something like the Creston or Saskatoon Sectionals (all three places being on standard time all year), but they're used to it, I guess, so they'd know.

Like anything with time parsing, all I can say is "I'm glad I'm not doing it (again)"! Thanks for the work making it work.

[Walddk]

I still claim that automation is a step in the wrong direction. Because no machine can spot the following human error:


Mitravihar club Centenary State level championship 2012
Nashik , India

Saturday, 2012-10-27

00:30-02:30

Semi Finals 1/2 (2 tables)

08:30-10:00

Quarter Finals 1/2 (2 tables)

09:30-11:00

Quarter Finals 2/2 (2 tables)


Sunday, 2012-10-28

04:30-06:30

Semi Finals 2/2 (2 tables)


Only a human realises that you can't play one segment of a semifinal before the quarterfinals, and it would have been a no-brainer for him/her to correct if he/she had been approached by the organiser.

[Walddk]

You also have to be a machine to think it's a good idea to run a tournament like this ....

INDIAN Corprorate Bridge Tournament
New Delhi, India

Saturday, 2012-09-15

21:45-23:45

Pairs session 2 (1 tables)


Sunday, 2012-09-16

00:15-02:15

Pairs session 3 (1 tables)


06:00-09:00

Pairs session 1 (1 tables)

...

Nothing wrong with technology, of course; a human made the error, but this could also have been avoided before it hit the schedule page.

[barmar]

 mycroft, on 2012-September-04, 10:14, said:

Ah, you're using the Microsoft-style zones. I can see that. '

I'm not sure what that refers to. It's just a hard-coded HTML menu.

Quote

The IANA standard (which linux, et al. uses) is Continent/City, using the tz_database. It's - barking huge (Wikipaedia URLs).

That database is needed for translating arbitrary dates in the past and future between time zones. It's overkill for this, where we're never dealing with dates more than a month or two in the future, and we don't have to worry about dates in the past at all.

Quote

Not so sure on the commentator's end, though, but you don't seem to be having much issues with "this page shows everything in your time" on the VuGraph web page, so I guess that's worked out too.

The way the schedule page displays times is totally unchanged since the old system.

Quote

As long as something works. I'm not 100% sure how I'd set up the upcoming Phoenix Regional or something like the Creston or Saskatoon Sectionals (all three places being on standard time all year), but they're used to it, I guess, so they'd know.

I don't see the problem. Select the appropriate timezone (Mountain Time for Phoenix), leave DST unchecked. The DST checkbox doesn't refer to whether the organizer is in DST now, it refers to whether DST will be in effect at the time and place of the tourney.

[barmar]

 Walddk, on 2012-September-04, 14:16, said:

I still claim that automation is a step in the wrong direction. Because no machine can spot the following human error:

We don't even try.

Quote

Only a human realises that you can't play one segment of a semifinal before the quarterfinals, and it would have been a no-brainer for him/her to correct if he/she had been approached by the organiser.

It's the organizer who enters the times in the first place.

If they make a mistake, let them know. It's easy to correct. In fact, I just checked and it already has been. Looks to me like he simply misclicked on the date for the Semi-Final 1/2.

[jallerton]

 barmar, on 2012-September-05, 09:02, said:

We don't even try.

It's the organizer who enters the times in the first place.

If they make a mistake, let them know. It's easy to correct. In fact, I just checked and it already has been. Looks to me like he simply misclicked on the date for the Semi-Final 1/2.

No, the organiser from the Indian event used the correct day (entering in Indian Time, presumably) but entered a session due to start at 2.15pm as 02:15. It's actually quite an easy mistake to make if you don't always think in terms of 24 hour clocks and are not used to completing forms of this type.

To reduce the chances of this sort of error being repeated, I have a few suggestions:

1. The 'drop down box' for the start time of the session currently defaults at the top just before midnight. Is it possible for the default position to be moved to midday or thereabouts?

2. If more than one session is being entered, perhaps your program could recognise when (say) the session on line 2 is due to start before the session on a previous line; the program could then report this error to the person who is attempting to input the event details, suggesting (or forcing) a correction there and then.

3. It would be a good idea for somebody to check the vugraph schedule every few days, to identify any obvious errors.

[Walddk]

 jallerton, on 2012-September-08, 16:27, said:

3. It would be a good idea for somebody to check the vugraph schedule every few days, to identify any obvious errors.

I did that every time a new event was listed. Desi and I spotted very few mistakes, and they were corrected immediately afterwards. Even if I wanted to, I can't do it any more, because I don't know what the organisers enter when they fill in the form. That's exactly why it was a good idea that they approached me first; not in order to determine whether the broadcasts were worthy of our attention (they all were/are), but simply to ensure that times were what they were meant to be.

Additionally, quite a few organisers don't speak or write English very well, some not at all, so they wrote to me in Norwegian, Swedish and German and a couple of other languages I speak. I was in a position to translate before I forwarded the relevant info. This is also a thing of the past. The latest example is a broadcast from Norway, an email I forwarded to vugraph@ (as requested by Uday) upon arrival on August 29th. This tournament has not made it to the schedule page yet, presumably because it's in Norwegian and has been sent back to the organisers for translation.

Finally, the fact that I received the details well in advance made it so much easier to select relevant events for voice commentary and approach potential commentators with some time to spare. So those of you who were not sure why I stepped down may understand it better now.

What might still have been has turned into automation, although I even offered to do it all myself if it was a burden for Desi to set it up on the web page. This point was ignored when I got replies from Uday and Rain. I tried to convince the management that full automation is not a good idea, but I did not succeed. I saw it as a "take it or leave it", so I left it.

[barmar]

 jallerton, on 2012-September-08, 16:27, said:

1. The 'drop down box' for the start time of the session currently defaults at the top just before midnight. Is it possible for the default position to be moved to midday or thereabouts?

Sounds reasonable.

FYI, when I was originally designing the form, I had one menu for the time, instead of separate hour/minute menus. It had entries for every 15-minute interval, was in AM/PM format, and it started at something like 8am. But then I noticed events on the schedule that started at times like xx:20, so I split it into the separate menus. It then didn't seem right to put AM/PM in the hour menu, because it would look like "1 PM:15", which is unnatural, so I switched to 24-hour format.

Quote

2. If more than one session is being entered, perhaps your program could recognise when (say) the session on line 2 is due to start before the session on a previous line; the program could then report this error to the person who is attempting to input the event details, suggesting (or forcing) a correction there and then.

After seeing these errors, what I'm thinking of doing is adding a preview of the event to the request and BBO approval pages, so we can see how the event will look on the schedule before posting it.

I'm a little wary of adding active checks like you suggest, since there might be concurrent events within the same tournament, and I don't want to force entering them all in time order. E.g. at the NABC, you might want enter all the sessions of the Spingold, then go back and enter all the sessions of the Wagar.

[ahollan1]

I've just used the online signup mechanism for the first time.

Here are a few observations

1) There should be separate threads for comments about
a) interface for commentators
b) interface for tournament hosts
c) general discussion of the topic
d) changes that affect vugraph within BBO software [only if that activity will ever be in play]

2) Fred's recent post [not sure if it was this thread or the other "automation" thread hinted at some BBO goals, but as a former software engineer geek, the lack of communicated requirement/design/implementation plans restricts most comments to bandaids for the vugraph schedule interface. {in spite of gut level instinct to expand on that, i'll leave it for another day IF there is interest}

The rest of this tome is based on the simple[simplistic] assumption that a goal is to make it easier for BBO to ungag/gag commentators. Hopefully there is or will be more to it than that, but that is beyond the current scope

3) Specific to the sign-up interface for commentators

a) after scrolling down to entries for Buffett Cup, I clicked on a session and ...
was immediately returned to the top of the page

b) scrolled down again to Buffett Cup entries, noticed chosen session was highlighted then selected 2nd set ...

Hopefully you see where this is going.

Each session selection required re-scroll to locate, selection, then re-scroll to confirm

As an User Interface that is almost double-dummy awful

Requirement:

R1: Provide quick/easy way to get to/select specific tournament
R2: Within tournament, provide mechanism for selection of multiple sessions before entry submission
R3: Provide at least one feedback mechanism to confirm the data entry
R3a: this can be immediate that shows just selections made
R3ai: show both selections made and remaining sessions for that tourney that were NOT chosen
R3b: delayed feedback [presumably e-mail] that lists:
R3bi: name of tourney just affected
R3bii: list of sessions just affected [include date, time and session name]
R3biii: URL to tournament page if one exists
R3biv: URL to official CCs submitted for the tourney, if one exists
[oops seems i've let slip hints at requirements for interface with host]
R3bv: identification of room(s) that want to restrict commentary to language other than english
[now i've also let slip possible requirement for display of schedule and possibly with change to BBO s/w -- oh my]
R3c: regardless of immediate/delayed feedback, for each entry show the selection of written vs voice
R4: Tool must do sanity check to prevent a commentator from double booking time slot(s)
[automation should do sanity checking in other areas too, but I digress]


Without attempting to mimic a host, I can imagine a list of requirements for that interface.
But I'll leave that for another entry and only if there is interest.

Last note: If BBO is really going to automatically gag after completion of a set [hinted at in earlier entry for one of the threads], well ... that is easy to code and I predict doomed to fail on multiple levels. But that goes back to inability to comment without having seen real requirements/goals/plans, etc.

Al

[jallerton]

Quote

I'm a little wary of adding active checks like you suggest, since there might be concurrent events within the same tournament, and I don't want to force entering them all in time order. E.g. at the NABC, you might want enter all the sessions of the Spingold, then go back and enter all the sessions of the Wagar.

There are different types of active checks. One possibility is to refuse to accept sessions being posted out of sequential order; another is just to provide a "warning: are you sure?" type.