秋田预测市场 · Discord 审计

深圳温度市场因数据源错误面临结算争议

2026-07-07 · Polymarket · 4 条相关讨论

georgster 2026-07-06 21:39:46

Heads up on Shenzhen July 6 (and the whole SZ series) — handing this off to anyone who wants to act on it, as I'll be offline when the resolution proposal lands. The rules name Shenzhen Bao'an Airport Station, resolving via the WU history page for ZGSZ. But the api.weather.com feed behind that page tags every row obs_id 45035, obs_name "Lau Fau Shan" — an HKO station across Deep Bay in Hong Kong, not Bao'an. Verified 3 ways today (files attached): - Raw feed JSON: "Lau Fau Shan" / 45035 on all rows, reproduced by two independent script runs - HKO's own published LFS series matches the WU rows hour-by-hour (mean diff 0.51C over 16 hrs; noon peak 29.2C vs WU 29C) - The actual Bao'an record (ZGSZ METAR tape) hit 31C today — a value that appears nowhere in the WU feed, which maxes at 29C. The series differ every hour with sign flips (12:00 local: airport rain-cooled to 27C while the WU feed printed its 29C daily peak — two different locations having different weather) Bonus defect: WU's hourly sampling even missed LFS's own 30.2C peak at 13:00, so the settlement number is a lossy sample of the wrong station. Net: the expected 29C proposal = a Hong Kong station's reading; the station named in the rules recorded 31C. Timing for anyone considering a dispute: data finalizes at the first July 7 datapoint on the WU page (~00:30–01:00 SZ time / ~16:30 UTC), proposal likely lands shortly after, standard challenge window applies from there. wethr.net also flags data accuracy issues on its SZ page. Polymarket support has been emailed requesting pre-resolution clarification. Everything needed to independently verify or dispute is in the attached files — timestamps included. Free to use, no coordination needed. Disclosure: I hold a position in this market.

Heads up on Shenzhen July 6 (and the whole SZ series) — handing this off to anyone who wants to act on it, as I'll be offline when the resolution proposal lands. The rules name Shenzhen Bao'an Airport Station, resolving via the WU history page for ZGSZ. But the api.weather.com feed behind that page tags every row obs_id 45035, obs_name "Lau Fau Shan" — an HKO station across Deep Bay in Hong Kong, not Bao'an. Verified 3 ways today (files attached): - Raw feed JSON: "Lau Fau Shan" / 45035 on all rows, reproduced by two independent script runs - HKO's own published LFS series matches the WU rows hour-by-hour (mean diff 0.51C over 16 hrs; noon peak 29.2C vs WU 29C) - The actual Bao'an record (ZGSZ METAR tape) hit 31C today — a value that appears nowhere in the WU feed, which maxes at 29C. The series differ every hour with sign flips (12:00 local: airport rain-cooled to 27C while the WU feed printed its 29C daily peak — two different locations having different weather) Bonus defect: WU's hourly sampling even missed LFS's own 30.2C peak at 13:00, so the settlement number is a lossy sample of the wrong station. Net: the expected 29C proposal = a Hong Kong station's reading; the station named in the rules recorded 31C. Timing for anyone considering a dispute: data finalizes at the first July 7 datapoint on the WU page (~00:30–01:00 SZ time / ~16:30 UTC), proposal likely lands shortly after, standard challenge window applies from there. wethr.net also flags data accuracy issues on its SZ page. Polymarket support has been emailed requesting pre-resolution clarification. Everything needed to independently verify or dispute is in the attached files — timestamps included. Free to use, no coordination needed. Disclosure: I hold a position in this market.

Vince 2026-07-07 05:06:41

Good work and very detailed! Shenzhen has been like this for quite a while. It's just one of the many quirks with WU. It's something to be aware of but the markets are resolved based on what's displayed on the resolution page, `https://www.wunderground.com/history/daily/cn/shenzhen/ZGSZ` regardless of where the underlying data is from.

Good work and very detailed! Shenzhen has been like this for quite a while. It's just one of the many quirks with WU. It's something to be aware of but the markets are resolved based on what's displayed on the resolution page, `https://www.wunderground.com/history/daily/cn/shenzhen/ZGSZ` regardless of where the underlying data is from.

georgster 2026-07-07 05:46:22

i get that thanks well if WU resolution page resolves to another location, do you know of any other cities that have this "quirk"? thanks in advance

i get that thanks well if WU resolution page resolves to another location, do you know of any other cities that have this "quirk"? thanks in advance

Vince 2026-07-07 08:53:08

Seoul gets weird sometimes. Here's a good one https://discord.com/channels/710897173927297116/1478933105262858321/1497928670612820039 Null values in the data makes zero degrees in both Celsius and Fahrenheit. 0C <> 0F. Miami, Shenzhen & others. https://discord.com/channels/710897173927297116/1478933105262858321/1480921447454085162 https://discord.com/channels/710897173927297116/1478933105262858321/1486161160863613020 And then the daylight savings transition day screws everything up. https://discord.com/channels/710897173927297116/1478933105262858321/1480919525141647394 Just look through my old posts and you'll find more.

Seoul gets weird sometimes. Here's a good one https://discord.com/channels/710897173927297116/1478933105262858321/1497928670612820039 Null values in the data makes zero degrees in both Celsius and Fahrenheit. 0C <> 0F. Miami, Shenzhen & others. https://discord.com/channels/710897173927297116/1478933105262858321/1480921447454085162 https://discord.com/channels/710897173927297116/1478933105262858321/1486161160863613020 And then the daylight savings transition day screws everything up. https://discord.com/channels/710897173927297116/1478933105262858321/1480919525141647394 Just look through my old posts and you'll find more.