{
  "id": 11127478,
  "title": "Don't localize carrier scan timestamps. You are not storing an instant.",
  "url": "https://urgent.news/2026/10/01/dont-localize-carrier-scan-timestamps-you-are-not-storing-an-instant",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-01T06:42:11.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/support24htrack/dont-localize-carrier-scan-timestamps-you-are-not-storing-an-instant-1a0c"
  },
  "original_language": "en",
  "account": "When building a user interface for tracking packages, it's essential to avoid converting carrier-sent timestamps into a single instant. This common practice often leads to inaccurate information for customers. The reason is that a scan is merely a local wall-clock reading at the time it occurred, not an instant in time. Carriers typically don't publish the time zone offset with these readings. Therefore, a string like \"2026-09-30 21:49:00\" is simply the clock at the building where the package was scanned, not an exact moment in time. Without the offset, it's impossible to convert the timestamp to another time zone, and treating it as UTC while rendering it in the viewer's zone can result in fabricated times that don't exist. To prevent this, it's best to print the carrier's provided digits unconverted. Use UTC getters to retrieve the original digits unchanged. Rendering this as text and labeling whose clock it is ensures the accuracy of the information presented. If a timestamp has an offset, it should be converted freely, but the two types should be kept distinct in the schema. Recognize that not every scan has a time. In a sample of 27,000 delivery events, about 4% have only a date, not a time. When this happens, new Date() will display midnight, which is misleading and can cause customer complaints. It's crucial to treat the absence of a time as a distinct state and not automatically convert it to midnight. This distinction helps avoid miscommunication about delivery times. The format of timestamps can vary, so it's essential to account for different patterns, such as \"YYYY-MM-DD HH:MM:SS\" or \"July 20, 2026 9:00 PM\". Using regex to identify one format might cause the other to be misclassified as having no time. Be mindful of these variations when processing the data. Finally, while it's tempting to flag odd hours in the data, avoid this practice. Delivery scans show that peak delivery times are late morning to mid-afternoon and late evening, with a smaller percentage during late-night hours. Instead of warning customers about evening deliveries, focus on providing the location of the delivery scan. The location is a more relevant piece of information for customers, indicating whether they should check their porch or contact the seller for further assistance. By storing the offset-less string as text, labeling whose clock it is, treating the absence of a time as its own state, and focusing on the scan location, you can avoid common pitfalls in tracking package delivery timestamps.",
  "summary": "If you build order-tracking UI, you have almost certainly done this: new Date ( scan . timestamp ). toLocaleString () It looks correct. It is the single most common way tracking pages end up lying to customers, and the bug report you get back will not look like a timezone bug. It will look like this, which is a real support message we got this week: \"This morning my package said delivered at…",
  "key_points": [
    "Avoid converting carrier timestamps to a single instant",
    "Print unconverted carrier-provided digits",
    "Treat absence of time as distinct state"
  ],
  "editors_take": "Treating carrier-sent timestamps as local wall-clock readings and rendering them unchanged helps ensure accuracy and avoids miscommunication about delivery times, benefiting customers with reliable package tracking information.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}