The isitreadonlyfriday.com API aims to be a cost effective tool for programatically dertermining if the current date is considered a 'readonly' day.
The isitreadonlyfriday.com API can be used in a variety of projects. Currently the largest use of the API is in CICD Pipelines to avoid erronous deployments to production environments on readonly days.
POST https://isitreadonlyfriday.com/api/isitreadonlyfriday/
This endpoint allows you to provide us with the reason you're using the API. Feel free to let me know how you're using this API or use the other GET methods if you'd prefer not to.
Both offset and reason are required fields in the body. You should also set Content-Type to application/json.
{"offset":0,"reason":"Just trying it out!"}
reason field to know how people are using the API. Please avoid putting anything like timestamps or other changing data in here. I do store these reasons for analytics purposes (but nothing personally identifiable) for a period of time and I'd like to not blow my storage limit. I log each unique reason only once with a counter of how many times it's been used so feel free to use a static reason in your application. I just wanna know what you're doing with the API (and why some of you are hitting it every minute ;))
Will provide a JSON response indicating the following:
| Key | Value |
|---|---|
| readonly |
trueor falsedepending on if it is a readonly day |
offset |
The UTC offset used in the calculation. |
{"readonly":false,"offset":0}
GET https://isitreadonlyfriday.com/api/isitreadonlyfriday/
Will provide a JSON response indicating the following:
| Key | Value |
|---|---|
| readonly |
trueor falsedepending on if it is a readonly day |
offset |
The UTC offset used in the calculation. For this endpoint it defaults to 0 which is UTC |
{"readonly":false,"offset":0}
GET https://isitreadonlyfriday.com/api/isitreadonlyfriday/:tz
TZis a variable for the time zone abbreviation. Valid codes are in the table following. Unfortunately, I'm American, so I only put in the American ones. I would put the others but have you seen the time zone abbreviation list? Look at it here. It's ridiculous. If your timezone isn't here then I'm sorry, but you can always use the offset REST method for whatever you need!
| Time Zone Name | Time Zone Abbreviation |
|---|---|
| Eastern Standard Time | EST |
| Eastern Daylight Time | EDT |
| Central Standard Time | CST |
| Central Daylight Time | CDT |
| Mountain Standard Time | MST |
| Mountain DaylightTime | MDT |
| Pacific Standard Time | PST |
| Pacific Daylight Time | PDT |
Will provide a JSON response indicating the following:
| Key | Value |
|---|---|
| readonly |
trueor falsedepending on if it is a readonly day |
offset |
The UTC offset used in the calculation. Will depend on the time zone provided. |
GET https://isitreadonlyfriday.com/api/isitreadonlyfriday/CDT
{"readonly":false,"offset":-5}
GET https://isitreadonlyfriday.com/api/isitreadonlyfriday/:offset
offsetis a variable for the offset to use when calculating time. This will be the offset from UTC. Values can be between 12 and -12, inclusive.
Will provide a JSON response indicating the following:
| Key | Value |
|---|---|
| readonly |
trueor falsedepending on if it is a readonly day |
offset |
The UTC offset used in the calculation. Will match the offset given. |
GET https://isitreadonlyfriday.com/api/isitreadonlyfriday/9
{"readonly":false,"offset":9}
GET https://isitreadonlyfriday.com/api/cloudflare/
This endpoint is the same as the UTC one but will be routed to a CloudFlare worker rather than the Google CloudRun container. Will provide a JSON response indicating the following:
| Key | Value |
|---|---|
| readonly |
trueor falsedepending on if it is a readonly day |
offset |
The UTC offset used in the calculation. For this endpoint it defaults to 0 which is UTC |
| host |
The host that serviced the request. Includes the 3 letter airport code that served the request. |
{"readonly":false,"offset":0,"host":"cloudflare-ORD"}