Jump to content

Vugraph Automation


mrdct

Recommended Posts

we used to agree with Roland that in some matches where the turkish national team plays, the CR was reserved for Turkish commentary and the OR was for english language.

This was highly appreciated by hundreds of turkish members who liked to watch their countrymen in international competitions and enjoy commentary in their own language.

now I dont see how this system will work.

Link to comment
Share on other sites

Just added a few enhancements and fixes that were submitted by users:

 

1. Added the day of week to the date display (if you looked at the schedule during the past hour it thought today was Monday, but that's fixed now).

2. Rounds that you're scheduled to comment on are highlighted.

3. When checking whether you're already a commentator or event organizer, it's case-insensitive.

Link to comment
Share on other sites

My reason to join a table, is to try to learn something.... and that is a very big part of my BBO-experience.....

 

And I do not go in the first place to tables were Meckwell or Fantoni or Hamman-Zia, .... are playing, but I look were the outstanding commentators are, and I surely must have missed a few, sorry: Roland, Peter Lund, Henri Bethe, David Bird; Larry Cohen, Kit Woolsey (mostly written), Andrew Gumperz, Dan Neill, Al Hollander, Bill Jacobs, George Holland, Graham Osborne,Jack Oest, John Swanson,.... and a few (only a few) more, the scrable guy, another aussie, and... sorry I cannot remember all names... But the ones I named are really outstanding,and I want to thank them very much.

 

And indeed, written commenting, very, very often, very, very poor...... just noise...

 

Edited by Lurpoa
  • Upvote 1
Link to comment
Share on other sites

Well reading this with due respect.the written commentators are catered for.

But what are the arrangements for Voice commentator's?

having said that,I have written a seperate article from the Spectators point of view.

not wishing to Hi jack this Topic.and Barmar's approval :)

Link to comment
Share on other sites

  • 2 weeks later...
Sometimes an event is listed as broadcasting from more than one table. For example, four people have currently signed up for an event with two tables. Does the software tell the commentators who should be at which table, or are the commentators expected to sort this out at the time themselves?
Link to comment
Share on other sites

Currently they sort it out themselves, perhaps under instructions from the event organizer or BBO staff.

 

When I designed it, I purposely didn't put table assignments into it, because I wanted to allow commentators to switch tables as necessary. For instance, when the first table finishes, the commentators can go to the other table and join in the commentary.

Link to comment
Share on other sites

One issue that came up with the World Bridge Games, though, was that the organizer didn't even distinguish the different events. They created a single segment for all the simultaneous events, titled something like "Open, Women, Seniors SF". If they'd created 3 separate segments, that just happened to have the same start/end times, this would have allowed commentators to sign up for the specific event.

 

Another thing: we currently don't enforce any of this. We're still using the old manual gag/ungag mechanism. An ungagged commentator can chat at any vugraph table in any event. Automating this in the server is coming in the next phase.

Link to comment
Share on other sites

The new http://www.bridgebase.com/vugraph/request_new.php page neds a couple of improvements I think:

 

- There must be options to enter info in other languages. I already volunteered to Diana Eva to translate the page to Turkish.

- The "Description (optional)" field is unnecessary

- Must avoid using expressions like "URL". Why not simply call it the "Event Webpage" ?

- 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

Link to comment
Share on other sites

tz_data seems to be the classic - and probably is what you're using for the zones as it is :-). Unfortunately, it has, for -7 in North America, Boise and Denver (I'm mildly patriotic, so that's out) and...that other city up the road. Imagine living in Boston and your computer telling you you have to be on America/New York City time...
Link to comment
Share on other sites

- 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

 

Yes, lumping together South Africa with Kallingrad is particularly interesting as the latter is now GMT+3 all year round, always one hour ahead of the former. Equally, Nairobi is not in the same time zone as Turkey, even though they may share the same time currently!

 

I would suggest that each time zone is split into places which use Summer Time for part of the year and those which do not.

Link to comment
Share on other sites

...

 

I would suggest that each time zone is split into places which use Summer Time for part of the year and those which do not.

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.

Link to comment
Share on other sites

tz_data seems to be the classic - and probably is what you're using for the zones as it is :-). Unfortunately, it has, for -7 in North America, Boise and Denver (I'm mildly patriotic, so that's out) and...that other city up the road. Imagine living in Boston and your computer telling you you have to be on America/New York City time...

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.

Link to comment
Share on other sites

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://michaelapproved.com/articles/timezone-dropdown-select-list. So it's Michael Khaili's fault. :)

 

- 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.

Link to comment
Share on other sites

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.

 

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.

Link to comment
Share on other sites

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.

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.

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

  • Upvote 1
Link to comment
Share on other sites

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.

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:

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.

Link to comment
Share on other sites

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
     

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...