Bug Report
Description
The /stats API endpoint appears to have a logical inconsistency in its data reporting. The stats.today.up field incorrectly reports the counter's all-time total count, rather than the count for the current UTC day.
This is directly contradicted by the stats.temporal.weekdays object within the same response, which correctly shows the counts distributed across multiple days. This makes it impossible to reliably track daily statistics using the /stats endpoint.
Live API Endpoint to Reproduce
The issue can be observed directly and consistently at the following public API endpoint:
https://api.counterapi.dev/v2/izumi-github-homepage/total-visits/stats
Steps to Reproduce
- Make a GET request to the URL above.
- Observe the JSON response.
- Compare the value of
stats.today.up with the total up_count.
- Compare the value of
stats.today.up with the distribution of counts in stats.temporal.weekdays.
Actual Behavior
As of reporting, the endpoint returns the following data structure (simplified for clarity):
{
"up_count": 33,
"stats": {
"today": {
"up": 33, // Incorrect: This should be the count for the current day only.
"down": 0
},
"this_week": {
"up": 33,
"down": 0
},
"temporal": {
"weekdays": {
"monday": { "up": 7, "down": 0 },
"sunday": { "up": 14, "down": 0 },
"tuesday": { "up": 12, "down": 0 }
// Other days are 0
}
}
}
}Analysis of the Contradiction:
- The total
up_count is 33.
- The
stats.today.up field also shows 33.
- However, the
stats.temporal.weekdays object clearly proves that these 33 counts occurred over three separate days: Sunday (14), Monday (7), and Tuesday (12).
This is a logical flaw. The today count cannot equal the total lifetime count when the counts are demonstrably spread across multiple days.
Expected Behavior
The stats.today.up value should accurately reflect the number of increments for the current UTC day. Based on the weekdays data:
- If the current UTC day is Tuesday,
stats.today.up should be 12.
- If the current UTC day is Wednesday,
stats.today.up should be 0 (or a new count for Wednesday).
The current implementation renders the today field in the /stats endpoint unreliable for its intended purpose. Thank you for your attention to this matter.
Bug Report
Description
The
/statsAPI endpoint appears to have a logical inconsistency in its data reporting. Thestats.today.upfield incorrectly reports the counter's all-time total count, rather than the count for the current UTC day.This is directly contradicted by the
stats.temporal.weekdaysobject within the same response, which correctly shows the counts distributed across multiple days. This makes it impossible to reliably track daily statistics using the/statsendpoint.Live API Endpoint to Reproduce
The issue can be observed directly and consistently at the following public API endpoint:
https://api.counterapi.dev/v2/izumi-github-homepage/total-visits/stats
Steps to Reproduce
stats.today.upwith the totalup_count.stats.today.upwith the distribution of counts instats.temporal.weekdays.Actual Behavior
As of reporting, the endpoint returns the following data structure (simplified for clarity):
{ "up_count": 33, "stats": { "today": { "up": 33, // Incorrect: This should be the count for the current day only. "down": 0 }, "this_week": { "up": 33, "down": 0 }, "temporal": { "weekdays": { "monday": { "up": 7, "down": 0 }, "sunday": { "up": 14, "down": 0 }, "tuesday": { "up": 12, "down": 0 } // Other days are 0 } } } }Analysis of the Contradiction:
up_countis 33.stats.today.upfield also shows 33.stats.temporal.weekdaysobject clearly proves that these 33 counts occurred over three separate days: Sunday (14), Monday (7), and Tuesday (12).This is a logical flaw. The
todaycount cannot equal the total lifetime count when the counts are demonstrably spread across multiple days.Expected Behavior
The
stats.today.upvalue should accurately reflect the number of increments for the current UTC day. Based on theweekdaysdata:stats.today.upshould be 12.stats.today.upshould be 0 (or a new count for Wednesday).The current implementation renders the
todayfield in the/statsendpoint unreliable for its intended purpose. Thank you for your attention to this matter.