Added references to new time based sync demo

intro/examples.mdx

@@ -93,6 +93,7 @@
     - [Yjs CRDT Text Collaboration Demo](https://github.com/powersync-ja/powersync-js/tree/main/demos/yjs-react-supabase-text-collab#readme)
     - [Vite + React + TS + PowerSync + Supabase](https://github.com/powersync-community/vite-react-ts-powersync-supabase#readme)
     - [E2EE Chat App](https://github.com/powersync-community/react-supabase-chat-e2ee#readme) - End-to-end encrypted group chat demo
+    - [Time-Based Sync Demo](https://github.com/powersync-ja/powersync-js/tree/main/demos/react-supabase-time-based-sync) - Dynamically control which data is synced to the client based on a date
 
     #### Framework Integration Examples
 
@@ -214,7 +215,7 @@
   <Accordion title="Flutter Projects" icon="flutter">
     - [Flutter Instagram Clone with Supabase + Firebase by @Gambley1](https://github.com/Gambley1/flutter-instagram-offline-first-clone)
     - [Jepsen PowerSync Testing - Formal consistency validation framework by @nurturenature](https://github.com/nurturenature/jepsen-powersync)
     - [Bavard -An Eloquent-inspired ORM for Dart/Flutter by @ILDaviz](https://ildaviz.github.io/bavard/)
   </Accordion>
   <Accordion title="JavaScript & TypeScript Projects" icon="js">
     - [SolidJS Hooks for PowerSync Queries by @aboviq](https://github.com/aboviq/powersync-solid)

sync/advanced/sync-data-by-time.mdx

@@ -45,7 +45,7 @@
 ```sql
 ALTER TABLE issues ADD COLUMN updated_this_week BOOLEAN DEFAULT false;
 ```
 Update it periodically using a cron job (e.g., with pg_cron):
 
 ```sql
 UPDATE issues SET updated_this_week = (updated_at > now() - interval '7 days');
@@ -57,9 +57,9 @@
     config:
       edition: 3
     streams:
       recent_issues:
         auto_subscribe: true
         query: SELECT * FROM issues WHERE updated_this_week = true
     ```
 
     For multiple time ranges, define a stream per range and let the client subscribe to the one it needs:
@@ -86,10 +86,10 @@
   </Tab>
   <Tab title="Sync Rules (Legacy)">
     ```yaml
     bucket_definitions:
       recent_issues:
         data:
           - SELECT * FROM issues WHERE updated_this_week = true
     ```
 
     For multiple time ranges, add multiple bucket definitions and let the client choose which bucket to sync:
@@ -122,7 +122,7 @@
 This approach works well when you have a small, fixed set of time ranges. However, it requires schema changes and a scheduled job to keep the columns updated.
 
 <Warning>
 This approach requires schema changes and scheduled jobs (e.g., pg_cron). Limited to pre-defined time ranges.
 </Warning>
 
 If you need more flexibility like letting users pick arbitrary date ranges, see Workaround 2 below.
@@ -133,13 +133,15 @@
 
 Use `substring` to extract the date portion from a timestamp and match it with `=`:
 
+For a complete working example, see the [PowerSync + Supabase: Time-Based Sync demo](https://github.com/powersync-ja/powersync-js/tree/main/demos/react-supabase-time-based-sync).
+
 <Tabs>
   <Tab title="Sync Streams">
     ```yaml
     config:
       edition: 3
     streams:
       issues_by_date:
         query: SELECT * FROM issues WHERE substring(updated_at, 1, 10) = subscription.parameter('date')
     ```
 
@@ -155,8 +157,8 @@
   </Tab>
   <Tab title="Sync Rules (Legacy)">
     ```yaml
     bucket_definitions:
       issues_by_update_at:
         parameters: SELECT value as date FROM json_each(request.parameters() ->> 'dates')
         data:
           - SELECT * FROM issues WHERE substring(updated_at, 1, 10) = bucket.date
@@ -184,9 +186,9 @@
 
 You have to pick a granularity and stick with it. If that's a problem—say, you want hourly precision for recent data but don't want hundreds of buckets when syncing a full month, see Workaround 3 below.
 
 ## 3: Multiple Granularities
 
 Combine multiple granularities in a single definition. This lets you use larger buckets (days) for older data and smaller buckets (hours, minutes) for recent data.
 
 <Tabs>
   <Tab title="Sync Streams">
@@ -194,7 +196,7 @@
     config:
       edition: 3
     streams:
       issues_by_partition:
         queries:
           # By day (e.g., "2026-01-07")
           - SELECT * FROM issues WHERE substring(updated_at, 1, 10) = subscription.parameter('partition')
@@ -220,8 +222,8 @@
   </Tab>
   <Tab title="Sync Rules (Legacy)">
     ```yaml
     bucket_definitions:
       issues_by_time:
         parameters: SELECT value as partition FROM json_each(request.parameters() ->> 'partitions')
         data:
           # By day (e.g., "2026-01-07")
@@ -257,11 +259,11 @@
 The trade-off is complexity. The client must decide which granularity to use for each time segment, and each row belongs to multiple buckets, which increases replication overhead.
 
 <Note>
 When using multiple time granularities (e.g., monthly, daily, hourly), rows move between buckets as time passes. Since each granularity creates a different bucket ID, the client must re-download the row from the new bucket even if it already has the data. This re-download overhead can nullify the benefits of granular filtering. For this reason, in some cases it may be better to sync entire months avoiding the re-sync overhead, even if you sync more data initially.
 </Note>
 
 <Warning>
 Each row belongs to multiple buckets (replication overhead). Re-sync overhead when rows move between bucket granularities. Added complexity may not justify the gains over Workaround 2.
 </Warning>
 
 # Conclusion
@@ -271,6 +273,6 @@
 
 - **Pre-defined time ranges** — Simplest option. Use when you have a fixed set of time ranges and don't mind schema changes.
 - **Buckets Per Date** — More flexible. Use when you need arbitrary date ranges but can live with a single granularity.
 - **Multiple Granularities** — Most flexible. Use when you need precision for recent data without syncing hundreds of buckets. Be mindful of the re-sync overhead.
 
 We're working on a more elegant solution. This guide will be updated when it's ready.