Yes. The widget reads IANA tz data and computes the current time in both zones from the row's from_zone and to_zone identifiers. Because the widget lives on the base WordPress page exactly once, fixing a DST handling bug or upgrading to a new tz database version applies to every pair page on the next page load. There is no per-post update sweep when the law changes.

Use IANA zone identifiers in the from_zone and to_zone columns rather than hardcoded offsets like UTC-5. IANA data carries the full DST rule set per zone so the widget computes the correct offset for any given moment, including the ambiguous and skipped hours around switch weekends. The dst_note column then explains the human consequence: the offset between this pair shifts twice a year.

Yes. If your widget supports an input field, add a default_meeting_time column for sensible business-hours defaults per pair like 09:00 in the source zone. The picker then highlights the corresponding time in the target zone. Surface the recommended overlap windows like 8-10am PT for IST teams or 2-4pm CET for EST teams in the intro through selector mapping.

Treat reverse pairs as separate rows with their own FAQs and overlap guidance. /time/ist-to-pst/ targets Indian-team-scheduling-US-meetings intent; /time/pst-to-ist/ targets US-team-scheduling-Indian-meetings intent. The math is symmetric but the audience perspective and the right overlap recommendations are different. Link them to each other through a related_slugs column.

Add a notes column for historical context where it matters. Some search queries still use deprecated abbreviations like EDT versus EST in casual phrasing. The dst_note column can clarify that the modern zone identifier covers both. For genuinely historical lookups, like converting times during the 2007 US DST extension, document the rule change in the FAQ rather than trying to compute it in the widget.

Event schema fits poorly for converter pages because there is no specific event happening. Stick to FAQPage schema from the FAQ list mapping. If a particular pair page is built around a known recurring event like the World Cup or a specific conference, add Event schema selectively via a per-row event_data column rather than baking it into every pair page in the group.

Update the dst_note column for the affected pairs and flush the cache. The IANA tz data update flows through the widget when you upgrade the library on the base page, so the live clock math stays accurate without per-page intervention. Recent examples include Mexico ending DST in 2022 and parts of the EU debating it. Treating DST notes as data rather than hardcoded copy makes these changes a sheet edit, not a content sprint.

Yes. The slug column drives the URL and should stay ASCII for stability, but the from_zone and to_zone display columns can carry localized names like Asia/Tokyo rendered as Tokyo in English or in Japanese for a Japanese-language site. Multi-language sites typically run one SleekRank page group per locale with separate sheets so each language has its own URL pattern and copy without mixing in the same group.