When working with dates in Yorlet, you should always use UTC.
  • Consistency: UTC provides a universal time reference, avoiding confusion with different time zones.
  • Accuracy: Using UTC ensures precise timing for events and transactions across global systems.
  • API compatibility: Yorlet’s API expects and returns unix timestamps in UTC.

​
Key considerations

  • In all API requests and responses, timestamps are in UTC format
  • Always convert local times to UTC before sending to Yorlet’s API
  • When displaying dates to users, convert from UTC to their local timezone
  • Use Unix timestamps for date values (e.g., 1704067200 for January 1st, 2024 00:00:00 UTC)

​
Working with dynamic timezones

Many regions observe daylight saving time, which creates dynamic timezone offsets throughout the year. This is particularly important when working with billing cycles, subscription renewals, and scheduled payments.

​
Example: British Summer Time (BST)

The United Kingdom observes British Summer Time from late March to late October, creating different UTC offsets:
  • Winter (GMT): UTC+0 - January 1st 00:00 local time = January 1st 00:00 UTC
  • Summer (BST): UTC+1 - June 1st 00:00 local time = May 31st 23:00 UTC
This means a subscription set to renew at midnight UK time will occur at different UTC times depending on the season.

​
Date configuration object

If you cannot directly specify a UTC timestamp for a date, you can instead define your desired date using a configuration object. Use the JSON format below to set a start date: 
{
  "start_date_config": {
    "day": 1,
    "month": 1,
    "year": 2025
  }
}
In this example, the start date is January 1st, 2025. Yorlet will automatically convert this configuration into the appropriate UTC timestamp for your account.

​
Special cases for end dates

When setting end-date configuration parameters (e.g., end_date_config), Yorlet automatically adjusts the time to 23:59:59. This ensures that the end date is fully inclusive.