Patching timestamp bc we need sort key granularity

Author: switch180

content/scenarios/Bank Payments/_index.en.md

@@ -13,7 +13,7 @@ This is primarily an OLTP workload with daily batch processes. Items in the tabl
 #### Workload dimensions
 
 - Accounts can have multiple payments scheduled for any day in the future.
-- Payments have the following data fields: *AccountID*, *ScheduledDate*, *Status* (`SCHEDULED`, `PENDING` or `PROCESSED`), *DataBlob* (total item size is <= 8 KB)
+- Payments have the following data fields: *AccountID*, *ScheduledTime*, *Status* (`SCHEDULED`, `PENDING` or `PROCESSED`), *DataBlob* (total item size is <= 8 KB)
 - One million automated scheduled payments are added every day at 1:00 AM *for that day*, which need to complete in 30 minutes.
 - One million payments are added every day with the `SCHEDULED` state, mostly in the hours of 6 AM to 6 PM.
 - During the day, a batch job runs regularly to query for today's `SCHEDULED` payments. This service sends the `SCHEDULED` items to the transaction service. Upon sending the items to the transaction service, the payment status is changed to `PENDING`.

content/scenarios/Bank Payments/references.en.md

@@ -16,7 +16,7 @@ The access patterns in the scenario are outlined as:
 
 Identify possible partitions keys to fulfill the primary access pattern:
 
-- What item attribute (*AccountID*, *ScheduledDate*, *Status*, *DataBlob*) scales with access patterns?
+- What item attribute (*AccountID*, *ScheduledTime*, *Status*, *DataBlob*) scales with access patterns?
 - What is a natural organization for the related payment items (so as to return collected items relative to the access patterns above)?
 - Consider the dimension of access: both reads and writes.