Szybki start Cennik

Strona główna → Pomoc

Znaczniki czasu w logu użycia nie zgadzają się z czasem wywołania

Większość platform przechowuje znaczniki czasu w UTC i wyświetla je albo w UTC, albo w strefie czasowej, którą raz ustawiłeś i o której zapomniałeś. Porównywanie lokalnego zegara z logiem w UTC przesuwa każdą granicę – dlatego sumy nie zgadzają się na krawędziach dnia.

Co widzisz

Dlaczego tak się dzieje

Dzienne sumy liczone są według granicy dnia. Jeśli twoja jest w UTC, a ty myślisz w UTC+8, osiem godzin wywołań ląduje w tym, co uważasz za poprzedni dzień – wszystkie dane są, tylko inaczej pogrupowane.

Znaczniki czasu po stronie klienta pochodzą z maszyny, która wykonała wywołanie. Serwer ze złym zegarem albo inną strefą czasową daje log, który wygląda na niespójny sam ze sobą.

Filtry często domyślnie pokazują ostatnie 24 godziny zamiast dzisiejszego dnia. To okno przesuwa się w trakcie oglądania, więc suma wydaje się zmieniać sama z siebie.

Jak to naprawić

  1. Porównuj w UTC po obu stronachPrzed uzgadnianiem przelicz własne zapisy na UTC. Robienie tego w drugą stronę wymaga strefy wyświetlania platformy, którą łatwo pomylić.
  2. Szukaj konkretnego żądania, a nie dniaSzukaj po id żądania albo po modelu i przybliżonym czasie. Pojedynczy wpis albo istnieje, albo nie – bez granicy, o którą można się spierać.
  3. Sprawdź zegar maszyny wywołującejJeśli twoje logi różnią się od platformy o stałe przesunięcie, które nie jest pełną liczbą godzin, podejrzewaj dryf zegara na maszynie wywołującej.
APICLAN zapisuje każde wywołanie w UTC z dokładną opłatą. Jeśli żądania naprawdę brakuje, a nie jest tylko przesunięte, zwykle oznacza to, że nigdy nie dotarło do bramki – błąd ścieżki albo base URL, który nie zostawia żadnego wpisu.

Powiązane

Unexpected token '<' przy wywołaniu API zgodnego z OpenAI401 invalid API key – gdy klucz wygląda dobrze, a i tak nie działa

Ostatnio sprawdzono 2026-10-01. Napisane na podstawie problemów zdiagnozowanych na działającej bramce zgodnej z OpenAI, a nie zebrane z innych stron.