{"id":50901354,"url":"https://github.com/centminmod/timezone-scheduler","last_synced_at":"2026-06-16T03:03:59.680Z","repository":{"id":346276736,"uuid":"1189145357","full_name":"centminmod/timezone-scheduler","owner":"centminmod","description":null,"archived":false,"fork":false,"pushed_at":"2026-03-23T05:17:34.000Z","size":13,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"master","last_synced_at":"2026-03-24T00:51:13.330Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/centminmod.png","metadata":{"files":{"readme":"readme.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-03-23T02:47:33.000Z","updated_at":"2026-03-23T05:17:37.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/centminmod/timezone-scheduler","commit_stats":null,"previous_names":["centminmod/timezone-scheduler"],"tags_count":null,"template":false,"template_full_name":null,"purl":"pkg:github/centminmod/timezone-scheduler","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/centminmod%2Ftimezone-scheduler","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/centminmod%2Ftimezone-scheduler/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/centminmod%2Ftimezone-scheduler/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/centminmod%2Ftimezone-scheduler/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/centminmod","download_url":"https://codeload.github.com/centminmod/timezone-scheduler/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/centminmod%2Ftimezone-scheduler/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34388669,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-16T02:00:06.860Z","response_time":126,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-06-16T03:03:55.454Z","updated_at":"2026-06-16T03:03:59.673Z","avatar_url":"https://github.com/centminmod.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Timezone Scheduler\n\n\u003e A meeting planner API for scheduling across timezones. Covers 80+ curated business hubs and 450+ IANA timezones. All times are DST-aware. Available at \u003chttps://timezones.centminmod.com\u003e\n\nThe Timezone Scheduler helps coordinate meetings across global timezones. It classifies each participant's local time into business hours (9 AM-5 PM), extended hours (7-9 AM or 5-9 PM), or off hours (9 PM-7 AM), and can suggest optimal meeting times.\n\nLet your AI LLM model learn how to use and setup the Timezone Scheduler as an API tool, AI Skill.md or MCP server by feeding the AI \u003chttps://timezones.centminmod.com/llms.txt\u003e.\n\n**Update:** See [readme-v2.md](readme-v2.md) for new benchmark comparisons with Google Gemma 4 31B, Qwen 3.6 Plus, GLM-5 Turbo, GLM-5V Turbo, Claude Code + Opus 4.6 1M.\n\n## Examples\n\n**Table of Contents**\n\n- [Timezone Scheduler API Example](#timezone-scheduler-api-example)\n  - [Prompt](#prompt)\n  - [Thinking](#thinking)\n  - [Response](#response)\n- [Comparison LLM Timezone Responses](#comparison-llm-timezone-responses)\n  - [Claude AI Opus 4.6 Web](#claude-ai-opus-46-web)\n  - [ChatGPT Plus - GPT-5.4 Thinking](#chatgpt-plus---gpt-54-thinking)\n  - [Google Gemini AI Pro - Gemini 3.1 Pro Thinking](#google-gemini-ai-pro---gemini-31-pro-thinking)\n  - [Google Gemini AI Pro - Gemini 3.1 Flash Lite](#google-gemini-ai-pro---gemini-31-flash-lite)\n  - [ZAI Coding Pro - GLM-5](#zai-coding-pro---glm-5)\n  - [MiniMax M2.7](#minimax-m27)\n  - [Moonshot Kimini K2.5 Thinking](#moonshot-kimini-k25-thinking)\n  - [Xiaomi Mimo V2 Pro](#xiaomi-mimo-v2-pro)\n  - [Xiaomi Mimo V2 Flash](#xiaomi-mimo-v2-flash)\n  - [Grok 4.20 Beta Thinking](#grok-420-beta-thinking)\n  - [Grok 4.1 Fast Thinking](#grok-41-fast-thinking)\n\n**Overall Response Quality Ranking**\n\nResponses scored out of 100 across 5 categories: **Time Optimization** (25 pts) — quality of recommended time slot using API scoring, 6/9=25, 5/9=17, 4/9=10; **DST Accuracy** (20 pts) — correctly identified daylight saving status for all 3 cities on March 23, 2026; **Timezone Math** (15 pts) — internal consistency of stated times across cities; **Analysis Quality** (20 pts) — depth of reasoning, options explored, trade-offs explained, no contradictions; **Practical Value** (20 pts) — alternatives offered, seasonal/DST-change notes, rotation suggestions, actionable format.\n\n| Rank | Source | Time (25) | DST (20) | Math (15) | Analysis (20) | Practical (20) | Total |\n| --- | --- | --- | --- | --- | --- | --- | --- |\n| 1 | [**Timezone Scheduler API (updated)**](#timezone-scheduler-api-example) | 25 | 20 | 15 | 20 | 20 | **100** |\n| 2 | [Timezone Scheduler API](#timezone-scheduler-api-example) | 25 | 20 | 15 | 19 | 19 | **98** |\n| 3 | [Gemini 3.1 Pro](#google-gemini-ai-pro---gemini-31-pro-thinking) | 25 | 20 | 15 | 14 | 12 | **86** |\n| 4 | [Grok 4.1 Fast](#grok-41-fast-thinking) | 25 | 18 | 15 | 15 | 12 | **85** |\n| 5 | [ChatGPT GPT-5.4](#chatgpt-plus---gpt-54-thinking) | 17 | 20 | 15 | 16 | 16 | **84** |\n| 6 | [Kimini K2.5](#moonshot-kimini-k25-thinking) | 17 | 20 | 15 | 15 | 17 | **84** |\n| 7 | [Mimo V2 Pro](#xiaomi-mimo-v2-pro) | 10 | 20 | 13 | 18 | 17 | **78** |\n| 8 | [Claude Opus 4.6](#claude-ai-opus-46-web) | 10 | 20 | 15 | 14 | 14 | **73** |\n| 9 | [Grok 4.20 Beta](#grok-420-beta-thinking) | 10 | 16 | 15 | 16 | 15 | **72** |\n| 10 | [Mimo V2 Flash](#xiaomi-mimo-v2-flash) | 17 | 14 | 15 | 15 | 10 | **71** |\n| 11 | [MiniMax M2.7](#minimax-m27) | 17 | 20 | 15 | 8 | 6 | **66** |\n| 12 | [Gemini Flash Lite](#google-gemini-ai-pro---gemini-31-flash-lite) | 17 | 12 | 15 | 10 | 10 | **64** |\n| 13 | [ZAI GLM-5](#zai-coding-pro---glm-5) | 17 | 5 | 5 | 14 | 12 | **53** |\n\nScore highlights:\n\n- **Timezone Scheduler API (updated)** (100) — perfect score after adding a comfort tie-break that formally optimizes for civil hours when business-hours scores are tied, automatically shifting the recommendation from midnight to 11 PM Brisbane\n- **Timezone Scheduler API** (98) — the original benchmark response before the comfort score update; near-perfect with a shareable scheduling link, DST-aware scoring, and multiple explored options — docked only for recommending midnight (comfort=3) over 11 PM (comfort=4)\n- **Gemini 3.1 Pro** (86) and **Grok 4.1 Fast** (85) — both found the optimal 6/9 time slot and independently chose the UTC 13:00 slot (now validated by the API's comfort tie-break) but lost points: Gemini for a contradictory Summary Recommendation that differed from its own #1 ranked pick, Grok for less detailed DST documentation\n- **ChatGPT GPT-5.4** (84) and **Kimini K2.5** (84) — didn't find the optimal time slot but delivered the most well-rounded responses with correct DST, source citations (ChatGPT), and seasonal variation notes (Kimini)\n- **Mimo V2 Pro** (78) — best analysis quality among LLMs (18/20) with a UTC business hours overlap table and rotation suggestion, held back by a suboptimal 4/9 time pick and a minor math error in a rejected option\n- **MiniMax M2.7** (66) — correct DST and math but recommends a time it marks as \"❌ Too early\" for New York (5:00 AM), then offers only vague alternatives\n- **ZAI GLM-5** (53) — lowest score due to incorrect London DST assumption (used BST instead of GMT), causing internally inconsistent timezone math\n\n**Quick Comparison: Recommended Meeting Times**\n\nEach source was given the same prompt for March 23, 2026 (Brisbane AEST UTC+10, New York EDT UTC-4, London GMT UTC+0). Times classified using the Timezone Scheduler API's hour categories and scoring: business (9 AM-5 PM) = 3 pts, extended (7-9 AM, 5-9 PM) = 2 pts, off (9 PM-7 AM) = 0 pts. Maximum possible score: 9/9. Comfort score: circular distance from 3 AM (scale 0-12) for the worst-off participant — used as a tie-break when business-hours scores are equal. Higher = more civil hour.\n\n\n\n| Source | Brisbane | New York | London | Score | Comfort |\n|---|---|---|---|---|---|\n| [**Timezone Scheduler API (updated)**](#timezone-scheduler-api-example) | 11:00 PM (off) | 9:00 AM (business) | 1:00 PM (business) | **6/9 (67%)** | **4** |\n| [Timezone Scheduler API](#timezone-scheduler-api-example) | 12:00 AM (off) | 10:00 AM (business) | 2:00 PM (business) | **6/9 (67%)** | 3 |\n| [Gemini 3.1 Pro](#google-gemini-ai-pro---gemini-31-pro-thinking) | 11:00 PM (off) | 9:00 AM (business) | 1:00 PM (business) | **6/9 (67%)** | **4** |\n| [Grok 4.1 Fast](#grok-41-fast-thinking) | 11:00 PM (off) | 9:00 AM (business) | 1:00 PM (business) | **6/9 (67%)** | **4** |\n| [ChatGPT GPT-5.4](#chatgpt-plus---gpt-54-thinking) | 8:00 PM (extended) | 6:00 AM (off) | 10:00 AM (business) | 5/9 (56%) | 3 |\n| [Kimini K2.5](#moonshot-kimini-k25-thinking) | 10:00 PM (off) | 8:00 AM (extended) | 12:00 PM (business) | 5/9 (56%) | **5** |\n| [Mimo V2 Pro](#xiaomi-mimo-v2-pro) | 7:00 AM (extended) | 5:00 PM (extended) | 9:00 PM (off) | 4/9 (44%) | 4 |\n| [Claude Opus 4.6](#claude-ai-opus-46-web) | 7:00 AM (extended) | 5:00 PM (extended) | 9:00 PM (off) | 4/9 (44%) | 4 |\n| [Grok 4.20 Beta](#grok-420-beta-thinking) | 7:00 AM (extended) | 5:00 PM (extended) | 9:00 PM (off) | 4/9 (44%) | 4 |\n| [Mimo V2 Flash](#xiaomi-mimo-v2-flash) | 6:00 AM (off) | 4:00 PM (business) | 8:00 PM (extended) | 5/9 (56%) | 3 |\n| [MiniMax M2.7](#minimax-m27) | 7:00 PM (extended) | 5:00 AM (off) | 9:00 AM (business) | 5/9 (56%) | 2 |\n| [Gemini 3.1 Flash Lite](#google-gemini-ai-pro---gemini-31-flash-lite) | 9:00 PM (off) | 7:00 AM (extended) | 11:00 AM (business) | 5/9 (56%) | 4 |\n| [ZAI GLM-5](#zai-coding-pro---glm-5) | 10:00 PM (off) | 8:00 AM (extended) | 1:00 PM (business) | 5/9 (56%) | 5 |\n\nKey observations:\n\n- No solution can score 9/9 — the 14-hour gap between Brisbane and New York makes simultaneous business hours mathematically impossible\n- The **Timezone Scheduler API**, **Gemini 3.1 Pro**, and **Grok 4.1 Fast** achieved the highest possible score (6/9) by placing 2 cities in core business hours — Gemini Pro and Grok 4.1 Fast both independently picked the same UTC 13:00 slot\n- With the comfort tie-break, the updated API now picks 11 PM Brisbane (comfort=4) over midnight (comfort=3) — its top pick now matches what Gemini Pro and Grok 4.1 Fast independently chose (UTC 13:00)\n- 3 models (Claude, Mimo V2 Pro, Grok 4.20 Beta) recommended the same 21:00 UTC slot, scoring 4/9 — prioritizing no one being asleep over maximizing business hours\n- 6 out of 11 LLMs scored 5/9, typically placing 1 city in business hours and 1 in extended hours\n- **Kimini K2.5** has the highest comfort score (5) among all entries despite only scoring 5/9 on business hours — it optimized for civil hours over business hours\n- **MiniMax M2.7** has the lowest comfort (2) due to NY at 5:00 AM being closest to the 3 AM nadir\n- **ZAI GLM-5** has a DST error — assumed London was already in BST (UTC+1) when London is still GMT (UTC+0) on March 23, making its 3 city times internally inconsistent by 1 hour\n- **Gemini 3.1 Flash Lite** incorrectly states a \"15 hour\" timezone spread between Brisbane and New York (it is 14 hours)\n\n### Timezone Scheduler API Example\n\nUpdate: after this benchmark, I made an improvement update to Timezones Scheduler API. I added a **Comfort score:** which is the circular distance from 3 AM (scale 0–12) used as a maximin tie-break so that when suggest slots tie on business-hours score, the slot where the worst-off participant has the most civil hour wins — making 11 PM rank above midnight and 9 PM above 2 AM.\n\n```bash\ncurl -sf \"https://timezones.centminmod.com/schedule/api?action=suggest\u0026from=Australia/Brisbane\u0026to=America/New_York\u0026to=Europe/London\u0026date=2026-03-23\" | python3 -c \"\nimport sys,json\nd=json.load(sys.stdin)\nfor i,s in enumerate(d['suggestions']):\n    src = s['sourceTime24h']\n    mc = s['minComfort']\n    parts = ' | '.join(f\\\"{t['name']} {t['time24h']} ({t['businessHours']})\\\" for t in s['times'])\n    print(f'{i+1}. {src} [comfort={mc}] {parts}')\n\"\n1. 23:00 [comfort=4] Brisbane 23:00 (off) | New York 09:00 (business) | London 13:00 (business)\n2. 23:15 [comfort=4] Brisbane 23:15 (off) | New York 09:15 (business) | London 13:15 (business)\n3. 23:30 [comfort=4] Brisbane 23:30 (off) | New York 09:30 (business) | London 13:30 (business)\n4. 23:45 [comfort=4] Brisbane 23:45 (off) | New York 09:45 (business) | London 13:45 (business)\n5. 00:00 [comfort=3] Brisbane 00:00 (off) | New York 10:00 (business) | London 14:00 (business)\n```\n\n#### Prompt\n\n\u003e Find the most optimal meeting time that works across Brisbane (Australia), New York (USA), and London (UK), ideally falling within business hours for all three cities, or as close to business hours as possible.\n\n#### Thinking\n\nThe suggest API returned the top 5 suggestions, all with score 6/9 (67%). The best it can do is have 2 out of 3 in business hours, with Brisbane always in \"off\" hours. Let me also try with a different source timezone to see if there's a better option, or let me try scheduling from different perspectives.\nActually, the API already optimized across all three. The fundamental challenge is that Brisbane (AEST, UTC+10) is far ahead of both New York (EDT, UTC-4) and London (GMT, UTC+0). That's a 14-hour gap between Brisbane and New York, which makes full business-hours overlap impossible.\nLet me explore if pushing to early morning Brisbane times—around 7 AM—might qualify as extended hours instead of off-hours, though the math shows this still lands outside business windows for the other locations.\n\n#### Response\n\nNow I'll use the `suggest` API to find optimal meeting times across all three cities.The `suggest` API's best results put Brisbane at midnight. Let me also check early-morning Brisbane slots that might land in \"extended\" hours, which the suggest endpoint may have ranked lower but could be more practical.Now let me check one more option to confirm the tradeoffs: scheduling from London's morning.Here's the full analysis based on the API results.\n\n**The core constraint:** Brisbane (UTC+10) and New York (UTC-4) are 14 hours apart. It is impossible to get all three cities into business hours (9 AM to 5 PM) simultaneously. One city will always be outside business hours.\n\n**Viable options explored:**\n\n| Option | Brisbane | New York | London | Tradeoff |\n|---|---|---|---|---|\n| **A. API's top pick** | 12:00 AM (off) | 10:00 AM (business) | 2:00 PM (business) | Brisbane sacrificed entirely |\n| **B. Brisbane early AM** | 7:00 AM (extended) | 5:00 PM (extended) | 9:00 PM (off) | London sacrificed |\n| **C. Brisbane evening** | 6:00 PM (extended) | 4:00 AM (off) | 8:00 AM (extended) | New York sacrificed |\n\n**The API's recommendation (Option A)** scored highest at 67% (6/9) because it puts two out of three participants in core business hours. The other two options only achieve \"extended\" hours for two participants with one still in off hours.\n\n**My recommendation: Option A** is the best overall pick, specifically **12:00 AM Brisbane / 10:00 AM New York / 2:00 PM London** on Monday March 23, 2026. It gives New York and London comfortable mid-day slots. The downside is that Brisbane is at midnight, but the alternative options only manage to push everyone into suboptimal extended/off slots rather than keeping two cities in their sweet spot.\n\nIf Brisbane absolutely cannot do midnight, **Option B (7:00 AM Brisbane)** is the best fallback: Brisbane gets an early but workable start, New York catches the end of day, and London takes the hit at 9 PM.\n\nShareable scheduling link for Option A: [View in Timezone Scheduler](https://timezones.centminmod.com/?m=eyJ2IjoyLCJmIjoiQXVzdHJhbGlhL0JyaXNiYW5lIiwiZCI6IjIwMjYtMDMtMjMiLCJoIjo3LCJtIjowLCJ0cyI6W3sidCI6IkFtZXJpY2EvTmV3X1lvcmsiLCJuIjoiTmV3IFlvcmsifSx7InQiOiJFdXJvcGUvTG9uZG9uIiwibiI6IkxvbmRvbiJ9XX0)\n\n\n### Comparison LLM Timezone Responses\n\nComparison native AI LLM model responses\n\n- [Claude AI Opus 4.6 Web](#claude-ai-opus-46-web)\n- [ChatGPT Plus - GPT-5.4 Thinking](#chatgpt-plus---gpt-54-thinking)\n- [Google Gemini AI Pro - Gemini 3.1 Pro Thinking](#google-gemini-ai-pro---gemini-31-pro-thinking)\n- [Google Gemini AI Pro - Gemini 3.1 Flash Lite](#google-gemini-ai-pro---gemini-31-flash-lite)\n- [ZAI Coding Pro - GLM-5](#zai-coding-pro---glm-5)\n- [MiniMax M2.7](#minimax-m27)\n- [Moonshot Kimini K2.5 Thinking](#moonshot-kimini-k25-thinking)\n- [Xiaomi Mimo V2 Pro](#xiaomi-mimo-v2-pro)\n- [Xiaomi Mimo V2 Flash](#xiaomi-mimo-v2-flash)\n- [Grok 4.20 Beta Thinking](#grok-420-beta-thinking)\n- [Grok 4.1 Fast Thinking](#grok-41-fast-thinking)\n\n#### Claude AI Opus 4.6 Web\n\nThere's no perfect overlap for all three cities, but let me map it out and find the best compromise.\n\n**Current offsets** (as of today, March 23, 2026):\n\n- Brisbane: UTC+10 (no daylight saving)\n- London: UTC+0 (GMT; clocks spring forward March 29)\n- New York: UTC-4 (EDT; started March 8)\n\nBrisbane is 10 hours ahead of London and 14 hours ahead of New York. That's a brutal spread, so someone will always be outside standard business hours.**The recommended slot is 7:00 AM Brisbane**, which lands at 5:00 PM New York and 9:00 PM London (both on the previous calendar day). Two of three cities are in or at the edge of business hours, and London at 9 PM is a reasonable ask for an important recurring meeting.\n\nIf Brisbane is willing to sacrifice instead, **9:00 PM Brisbane** flips the equation: London gets 11 AM, New York gets 7 AM, and Brisbane takes the late evening.\n\nThere is no time where all three fall within 9-to-5. The 14-hour gap between Brisbane and New York makes that mathematically impossible. One city always compromises.\n\n**Note:** London's clocks spring forward on March 29, shifting to BST (UTC+1). After that date, the London times above shift one hour later (e.g., 7 AM Brisbane becomes 10 PM London instead of 9 PM).\n\n#### ChatGPT Plus - GPT-5.4 Thinking\n\nViable options, with trade-offs:\n\n- **Brisbane 8:00 pm / London 10:00 am / New York 6:00 am**\n  Best overall balance. London stays comfortably in business hours, Brisbane is late but manageable, New York is early.\n\n- **Brisbane 9:00 pm / London 11:00 am / New York 7:00 am**\n  Easier for New York than 6:00 am, but Brisbane gets later.\n\n- **Brisbane 10:00 pm / London 12:00 pm / New York 8:00 am**\n  Good for London and acceptable for New York, but quite late for Brisbane.\n\n- **Brisbane 11:00 pm / London 1:00 pm / New York 9:00 am**\n  Fully inside business hours for London and New York, but very late for Brisbane.\n\n- **Brisbane 7:00 pm / London 9:00 am / New York 5:00 am**\n  Great for London, but too punishing for New York.\n\nI’d choose **Brisbane 8:00 pm, London 10:00 am, New York 6:00 am** as the most optimal compromise.\n\nWhy this one:\n\n- There is **no true overlap** where all three cities are simultaneously within normal business hours.\n- Right now, Brisbane is on **UTC+10**, New York is on **UTC-4** because US daylight saving already started on **March 8, 2026**, and London is still on **UTC+0** until UK clocks go forward on **March 29, 2026**. ([Time and Date][1])\n- Given those offsets, **8:00 pm Brisbane** lands at **10:00 am London** and **6:00 am New York**, which minimizes the worst inconvenience across the three locations better than the later Brisbane-heavy or earlier New York-heavy alternatives. This is an optimization judgment based on the current offsets.\n\nRecommended meeting time:\n\n- **8:00 pm Brisbane**\n- **10:00 am London**\n- **6:00 am New York**\n\nOne useful note: once the UK moves to daylight saving on **March 29, 2026**, that same Brisbane time becomes **11:00 am London** instead of 10:00 am, while New York stays at 6:00 am until later in the year. ([GOV.UK][2])\n\nFor a more human-friendly fallback set:\n\n- best balance: **8:00 pm Brisbane / 10:00 am London / 6:00 am New York**\n- New York-friendlier: **9:00 pm Brisbane / 11:00 am London / 7:00 am New York**\n- London and New York business-hours priority: **11:00 pm Brisbane / 1:00 pm London / 9:00 am New York**\n\nI can also give you a small recurring-meeting cheat sheet for these three cities across DST changes.\n\n[1]: https://www.timeanddate.com/time/change/usa?utm_source=chatgpt.com \"Daylight Saving Time 2026 in the United States\"\n[2]: https://www.gov.uk/when-do-the-clocks-change?utm_source=chatgpt.com \"When do the clocks change?\"\n\n#### Google Gemini AI Pro - Gemini 3.1 Pro Thinking\n\nFinding a single meeting time that falls within standard 9:00 AM to 5:00 PM business hours for Brisbane, New York, and London is mathematically impossible, as the time difference spans 14 hours. To accommodate all three, at least one city must meet outside of traditional office hours.\n\nBased on the current date of March 23, 2026, here are the time zone offsets:\n- **Brisbane (AEST):** UTC +10\n- **London (GMT):** UTC +0\n- **New York (EDT):** UTC -4\n\nHere are the three most optimal windows for a meeting, ranked by how close they get to standard business hours:\n\n##### 1. The Best Compromise (Focus on NY and London)\n\nThis is the most common choice for global teams because it captures two regions during their workday, while the third joins in the late evening.\n- **New York:** 9:00 AM\n- **London:** 1:00 PM\n- **Brisbane:** 11:00 PM\n- **Pros:** New York and London are both in the middle of their business day.\n- **Cons:** Brisbane is very late at night.\n\n##### 2. The Early/Late Shift (Focus on Brisbane and New York)\n\nThis option works well if the London participant is a \"night owl\" and the New York participant is finishing their day.\n- **Brisbane:** 8:00 AM (Next Day)\n- **New York:** 6:00 PM\n- **London:** 10:00 PM\n- **Pros:** Brisbane is just starting their workday; New York is only one hour past traditional business hours.\n- **Cons:** London is late at night.\n\n##### 3. The Morning/Evening Shift (Focus on London and Brisbane)\n\nThis slot is ideal for those in London and Brisbane, but it is very difficult for New York.\n- **London:** 8:00 AM\n- **Brisbane:** 6:00 PM\n- **New York:** 4:00 AM\n- **Pros:** London is starting their day; Brisbane is just finishing theirs.\n- **Cons:** New York is in the middle of the night.\n\n##### Summary Recommendation\n\nThe most \"equitable\" time is usually **12:00 PM London / 8:00 AM New York / 10:00 PM Brisbane**. In this scenario, London is in their mid-day, New York is just starting or slightly before their formal start, and Brisbane is at the end of their evening rather than the middle of the night.\n\n#### Google Gemini AI Pro - Gemini 3.1 Flash Lite\n\nTo determine an optimal meeting time, let's analyze the time zone differences relative to UTC:\n\n- **Brisbane (AEST):** UTC+10\n- **London (GMT/BST):** UTC+0 or UTC+1 (Depending on Daylight Saving)\n- **New York (EST/EDT):** UTC-5 or UTC-4 (Depending on Daylight Saving)\n\nCurrent date is March 23, 2026. At this time, all three locations are observing their respective standard or daylight savings times (Note: March 23 is typically the transition period).\n\n##### The Challenge\n\nThere is a significant geographic spread. When it is morning in Brisbane, it is overnight in New York and London. When it is business hours in New York, it is late evening/night in Brisbane.\n\n**Viable Options:**\n\n- **Option 1: Brisbane Morning / London Evening / New York Afternoon (Previous Day)**\n  - *Trade-off:* Requires someone to meet outside traditional 9-5 hours.\n- **Option 2: Brisbane Late Evening / London Morning / New York Early Morning**\n  - *Trade-off:* Brisbane stays up very late, New York starts very early.\n- **Option 3: Rotating shifts**\n  - *Trade-off:* No one suffers all the time, but it lacks consistency.\n\n##### Analysis and Recommendation\n\nMathematically, a 9-5 overlap for all three cities is impossible. The total spread is 15 hours (Brisbane is 15 hours ahead of New York).\n\n**Recommendation: The \"Bridge\" Slot**\n\nThe most viable compromise is usually early morning for one party and late evening for the other.\n\n- **Proposed Time:** 07:00 AM (New York) / 11:00 AM (London) / 09:00 PM (Brisbane)\n- **Why this works:**\n  - **New York (EST):** 7:00 AM (Early start, but professional).\n  - **London (GMT):** 11:00 AM (Mid-morning, prime business time).\n  - **Brisbane (AEST):** 9:00 PM (Late evening, but manageable for a single meeting).\n\nThis aligns London and New York perfectly within their respective business days while asking the Brisbane participant to take the meeting at the end of their day.\n\n**Alternative (The \"Other Way\"):**\n\n- **Proposed Time:** 10:00 PM (New York) / 2:00 AM (London) / 12:00 PM (Brisbane)\n- **Why this is usually worse:** This forces London into the middle of the night, which is significantly more disruptive than a late evening in Brisbane.\n\n**Conclusion:**\nAim for **07:00 AM (New York) / 11:00 AM (London) / 09:00 PM (Brisbane)**. It is the most sustainable slot that allows at least two parties to be in standard business hours and requires the third to work outside of them without being in the middle of the night.\n\n#### ZAI Coding Pro - GLM-5\n\nTo find the most optimal meeting time across Brisbane, New York, and London, we must look at the intersection of standard business hours (typically 9:00 AM to 5:00 PM).\n\nDue to the vast distance, there is **no \"perfect\" time** that falls strictly within 9–5 business hours for all three cities simultaneously. The geography makes this impossible because when it is afternoon in Brisbane, it is the middle of the night in New York.\n\nHowever, there is a highly optimal \"sweet spot\" that falls within business hours for two cities and requires only a slight adjustment for the third.\n\n##### The Optimal Meeting Time\n\n**Time:** **8:00 AM – 9:00 AM (New York Time)**\n\nHere is how this time translates across the three cities:\n\n- 🇦🇺 **Brisbane:** **10:00 PM – 11:00 PM** (Same day)\n  - *Verdict:* This is outside standard business hours, but it is a reasonable \"late evening\" slot that does not require waking up in the middle of the night.\n- 🇬🇧 **London:** **1:00 PM – 2:00 PM**\n  - *Verdict:* **Perfect.** This is right in the middle of the standard workday.\n- 🇺🇸 **New York:** **8:00 AM – 9:00 AM**\n  - *Verdict:* **Good.** This is just before standard office hours, but it is a very common time for early meetings or breakfast briefings.\n\n---\n\n##### Alternative: The \"Early Bird\" Option\n\nIf the New York team prefers to start at standard time (9:00 AM), and the Brisbane team is willing to stay up slightly later:\n\n**Time:** **9:00 AM – 10:00 AM (New York Time)**\n\n- 🇦🇺 **Brisbane:** **11:00 PM – 12:00 AM (Midnight)**\n  - *Verdict:* A bit late for Brisbane, but manageable for a one-off important meeting.\n- 🇬🇧 **London:** **2:00 PM – 3:00 PM**\n  - *Verdict:* **Perfect.** Still mid-afternoon.\n- 🇺🇸 **New York:** **9:00 AM – 10:00 AM**\n  - *Verdict:* **Perfect.** Standard morning start.\n\n##### Summary Recommendation\n\nThe best compromise is **8:00 AM New York / 1:00 PM London / 10:00 PM Brisbane**.\n\nThis is the only slot where two parties are operating completely within standard hours, and the third (Brisbane) is operating during reasonable waking hours (evening), rather than the New York team having to wake up at 4:00 AM or the London team having to stay until 9:00 PM.\n\n***Note on Seasons:** This calculation assumes standard time zones (Brisbane is UTC+10, London is UTC+1/BST, New York is UTC-4/EDT). If London is in Winter (GMT) and New York is in Winter (EST), the optimal window shifts to 3:00 PM London / 10:00 AM New York / 1:00 AM Brisbane. However, the \"8 AM NY / 1 PM London\" window is generally the standard convention for global teams during Northern Hemisphere summer.*\n\n#### MiniMax M2.7\n\n##### Time Zone Analysis\n\n**Current Date:** March 23, 2026\n\n**DST Status:**\n\n- US: EDT (UTC−4) — DST began March 8, 2026\n- UK: GMT (UTC+0) — BST begins March 29, 2026\n- Brisbane: AEST (UTC+10) — no DST\n\n**Business Hours (local):**\n\n| City | Local | UTC |\n|------|-------|-----|\n| London | 9:00–17:00 | 09:00–17:00 |\n| New York | 9:00–17:00 | 13:00–21:00 |\n| Brisbane | 9:00–17:00 | 23:00–07:00 |\n\n##### The Problem\n\nBrisbane's business hours (23:00–07:00 UTC) are **completely inverted** relative to London/New York (09:00–17:00 UTC). There is **no three-way overlap** during business hours.\n\n##### Optimal Compromise\n\n**Best meeting time: 09:00 UTC**\n\n| City | Time | Business Hours? |\n|------|------|-----------------|\n| London | 9:00 AM | ✅ Perfect |\n| New York | 5:00 AM | ❌ Too early |\n| Brisbane | 7:00 PM | ❌ After hours |\n\n**Alternative: 13:00–17:00 UTC** (5:00–9:00 AM NYC, 11 PM–3 AM Brisbane)\n\nThe reality is these three cities have minimal viable overlap. For a truly functional meeting, **two of the three participants must meet outside typical business hours**. I'd recommend either an early London morning (7:00–9:00 UTC) or a late New York evening slot.\n\n#### Moonshot Kimini K2.5 Thinking\n\nGiven the current date (March 23, 2026) and time zone offsets:\n\n- **Brisbane**: UTC+10 (AEST, no daylight saving)\n- **New York**: UTC-4 (EDT, daylight saving active)\n- **London**: UTC+0 (GMT, switches to BST on March 29)\n\nThere is no period where standard business hours (9 AM–5 PM) overlap for all three cities. The **optimal compromise** minimizes pain for all parties:\n\n##### Primary Recommendation\n\n**Brisbane: 10:00 PM – 11:00 PM**  \n**New York: 8:00 AM – 9:00 AM**  \n**London: 12:00 PM – 1:00 PM (midday)**\n\n- **Brisbane**: Late evening (post-dinner, manageable for critical meetings)\n- **New York**: Start of business day (standard working time)\n- **London**: Midday lunch hour (core business period)\n\n##### Alternative Option\n\nIf Brisbane prefers an early start over a late night:\n\n**Brisbane: 7:00 AM – 8:00 AM**  \n**New York: 5:00 PM – 6:00 PM**  \n**London: 9:00 PM – 10:00 PM**\n\n- **Brisbane**: Very early morning (start of day)\n- **New York**: End of business day (acceptable for many)\n- **London**: Late evening (outside standard hours)\n\n##### Seasonal Variations\n\n- **After March 29, 2026** (London BST/UTC+1): The 10 PM Brisbane slot becomes 1:00 PM in London (still ideal).\n- **Winter (Nov–Mar)**: When New York is EST (UTC-5), the 10 PM Brisbane slot becomes 7:00 AM in New York (one hour earlier, still viable) and 12:00 PM in London.\n\n**Verdict:** Schedule for **10:00 PM Brisbane time** (8:00 AM New York / 12:00 PM London). This hits active business hours in New York and London while keeping Brisbane at a manageable, if late, evening hour.\n\n#### Xiaomi Mimo V2 Pro\n\n##### Optimal Meeting Time Across Brisbane, New York \u0026 London\n\n##### Time Zone Snapshot (March 23, 2026)\n\n| City | Time Zone | UTC Offset |\n|------|-----------|------------|\n| Brisbane | AEST | UTC+10 |\n| New York | EDT (DST active since Mar 8) | UTC−4 |\n| London | GMT (DST starts Mar 29) | UTC+0 |\n\n##### The Hard Truth\n\nThe three cities span **14 hours** of time zones. A 9–5 business window for any one city lands squarely in the sleeping hours of the others:\n\n| Business Hours (local) | UTC Equivalent | In Brisbane | In New York | In London |\n|---|---|---|---|---|\n| Brisbane 9–17 | 23:00–07:00 | ✅ | 🌙 Sleeping | 🌙 Sleeping |\n| London 8–17 | 08:00–17:00 | 🌙 Sleeping | 🌙 Sleeping→4AM | ✅ |\n| New York 9–17 | 13:00–21:00 | 🌙 Sleeping | ✅ | 1PM–9PM ✅ |\n\n**No UTC window falls within all three business hours simultaneously.**\n\n##### Recommended Compromise\n\n###### Option A — Best for New York \u0026 London, early morning for Brisbane\n\n\u003e **7:00–8:00 AM Brisbane / 5:00–6:00 PM New York / 9:00–10:00 PM London**\n\n| City | Local Time | Status |\n|------|-----------|--------|\n| Brisbane | 7:00 AM | ⚠️ Early but workable (start of day) |\n| New York | 5:00 PM | ✅ End of business day |\n| London | 9:00 PM | ⚠️ Evening (after hours) |\n\n###### Option B — Best for Brisbane \u0026 New York, late night for London\n\n\u003e **4:00 PM Brisbane / 12:00 AM (midnight) New York / 4:00 AM London**\n\nThis doesn't work — pushes NY and London into sleeping hours.\n\n###### Option C — Best for Brisbane \u0026 London, very early for New York\n\n\u003e **4:00 PM Brisbane / 2:00 AM New York / 6:00 AM London**\n\nAlso poor — NY is asleep.\n\n##### Winner: Option A\n\n**7:00 AM Brisbane / 5:00 PM New York / 9:00 PM London (UTC 21:00)**\n\nThis is the optimal sweet spot because:\n\n- **New York** gets a fully within-hours meeting (5 PM).\n- **London** only stretches 2 hours past business hours (9 PM — reasonable for one-off calls).\n- **Brisbane** is early (7 AM) but at the start of the workday, which is more tolerable than a late night.\n\n###### Rotation Suggestion\n\nIf this is a recurring meeting, rotate the inconvenience:\n\n| Week | Brisbane | New York | London |\n|------|----------|----------|--------|\n| Week 1 | 7:00 AM | 5:00 PM ⬅️ | 9:00 PM |\n| Week 2 | 10:00 PM | 8:00 AM ⬅️ | 12:00 PM |\n\nThis keeps it fair — nobody always takes the off-hours slot.\n\n#### Xiaomi Mimo V2 Flash\n\nAfter considering the time zones and business hours for Brisbane (AEST, UTC+10), New York (EDT, UTC-4), and London (GMT, UTC+0), I evaluated several approaches to find an optimal meeting time. Here's a summary of the viable options with trade-offs:\n\n- **Option 1: 10:00 UTC**  \n  - London: 10:00 AM (within business hours)  \n  - New York: 6:00 AM EDT (3 hours before business hours)  \n  - Brisbane: 8:00 PM AEST (3 hours after business hours)  \n  - Trade-off: New York participants would need to start very early, and Brisbane participants would meet late in the evening.\n\n- **Option 2: 20:00 UTC**  \n  - London: 8:00 PM GMT (3 hours after business hours)  \n  - New York: 4:00 PM EDT (within business hours)  \n  - Brisbane: 6:00 AM AEST (3 hours before business hours)  \n  - Trade-off: London participants would meet late in the evening, and Brisbane participants would need to start early.\n\n- **Option 3: 15:00 UTC**  \n  - London: 3:00 PM (within hours)  \n  - New York: 11:00 AM (within hours)  \n  - Brisbane: 1:00 AM (next day, 8 hours before business hours)  \n  - Trade-off: Brisbane participants would have to meet in the middle of the night.\n\n- **Option 4: 01:00 UTC**  \n  - London: 1:00 AM (8 hours before business hours)  \n  - New York: 9:00 PM (4 hours after business hours)  \n  - Brisbane: 11:00 AM (within hours)  \n  - Trade-off: London and New York participants would meet outside typical evening hours.\n\n**Chosen Option:**  \nI recommend **20:00 UTC** as the most optimal time. This minimizes the maximum deviation from business hours (3 hours for London and Brisbane) while keeping New York within standard hours. It balances practicality, as 4:00 PM in New York is a common meeting time, and 6:00 AM in Brisbane or 8:00 PM in London might be acceptable for important meetings. Note that this assumes standard business hours (9 AM–5 PM local time) and does not account for daylight saving changes; always verify for the specific meeting date.\n\n**Local Times at 20:00 UTC:**  \n\n- London: 8:00 PM GMT  \n- New York: 4:00 PM EDT  \n- Brisbane: 6:00 AM AEST (next day)\n\n#### Grok 4.20 Beta Thinking\n\n**Viable options:**\n\n- **13:00 UTC (9am NY, 1pm London, 11pm Brisbane)**: Strong core business hours for New York and London; Brisbane is very late. Trade-off: two cities optimal, one significantly disrupted.\n- **22:00 UTC (8am Brisbane, 6pm NY, 10pm London)**: Good start for Brisbane, acceptable end-of-day for NY, late for London. Trade-off: favors the Australian user but pushes London past normal hours.\n- **21:00 UTC (7am Brisbane, 5pm NY, 9pm London)**: Brisbane in early business hours, NY at end of business, London slightly after hours. Trade-off: all times fall within extended reasonable working window (7am–9pm local).\n- **Alternating times across the three slots above**: Shares inconvenience fairly over multiple meetings. Trade-off: requires more scheduling coordination.\n\n**Chosen approach:** 21:00 UTC (7am Brisbane, 5pm New York, 9pm London).  \nThis is the most optimal single time because it keeps every participant within an extended but workable window (7am–9pm local), avoids anyone being awake at midnight or later, and balances the load rather than heavily favoring two cities at the expense of the third.\n\n**Recommended meeting time:**\n\n- **Brisbane**: 7:00 AM AEST\n- **New York**: 5:00 PM EDT\n- **London**: 9:00 PM GMT\n\nThis works on the current date (23 March 2026) and most days in this season. For recurring meetings, consider rotating between the top two options every other meeting to maintain fairness.\n\n#### Grok 4.1 Fast Thinking\n\n##### Viable Options (UTC times, assuming Mar 2026: Brisbane AEST UTC+10, New York EDT UTC-4, London GMT UTC+0)\n\n- **13:00 UTC** (NY 09:00, London 13:00, Brisbane 23:00): NY \u0026 London in business hours; Brisbane 6h after close (evening). Good balance, favors awake evening over sleep.\n- **14:00 UTC** (NY 10:00, London 14:00, Brisbane 00:00): NY \u0026 London in business; Brisbane 7h after close (midnight). Slightly worse offset for Brisbane.\n- **17:00 UTC** (NY 13:00, London 17:00, Brisbane 03:00): NY \u0026 London in business; Brisbane 6h before open (early morning). Sleep disruption risk.\n- **09:00 UTC** (NY 05:00, London 09:00, Brisbane 19:00): London in business; NY early, Brisbane after hours. Only one in business.\n- **21:00 UTC** (NY 17:00, London 21:00, Brisbane 07:00): NY in business; others after/before. Only one in business.\n\n**Chosen: 13:00 UTC** (NY 09:00 EDT, London 13:00 GMT, Brisbane 23:00 AEST). Maximizes participants in business hours (2/3), with Brisbane's offset being evening (post-work) rather than predawn sleep interruption. No triple overlap possible due to 14h NY-Brisbane span. For a 1-2h meeting, extend to 13:00-15:00 UTC (Brisbane 23:00-01:00). Adjust for DST changes (e.g., London BST from Mar 29).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcentminmod%2Ftimezone-scheduler","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcentminmod%2Ftimezone-scheduler","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcentminmod%2Ftimezone-scheduler/lists"}