Identify what each timestamp controls
An event notice can contain several clocks. Label each one before converting or adding it to a checklist, because a start, reset, participation end and claim deadline do not mean the same thing.
When does access begin?
Convert only when the notice states a date, time and UTC offset.When does participation close?
Keep the printed end boundary separate from any reward-claim deadline.What refreshes, and how often?
Apply the clock only to the named counter, quest or allowance.How long can rewards be collected?
Track it as a separate deadline when the source provides one.Convert only what the source defines
Swipe sideways to compare all columns →
| Notice wording | Status | Next action |
|---|---|---|
| Date + time + UTC offset | Convertible | Use Event Time Converter, then compare both calendar dates. |
| Date + server time | Needs context | Confirm your region and the offset displayed in the current client. |
| After update | No fixed instant | Wait for maintenance completion and confirm access in-game. |
| Older notice plus later change | Recheck | Use the newest official notice and retain the older page as history. |
Everness Atlas decision table. Preserve ambiguous wording until the current client or a later official notice resolves it.
Read the Reset Times guide for sourced examples of system refreshes, event allowances and UTC offsets.
Move from source to session without losing context
Run a four-part current check
Check whether a correction, extension or maintenance update supersedes the page you opened.
Confirm access, eligibility, remaining allowance and the clock shown for your region.
Choose a manageable task and leave a personal buffer before an end or claim deadline.
Update the checklist after play and keep unfinished work visible for the next session.
Dated example boundary: the September 9 page is an archived announcement record, not a live availability feed. Always verify the current event screen and newer official notices before spending resources.