stackexchange.user_answers

curl "https://api.onekey.dev/v1/stackexchange/user_answers?id=22656" \
  -H "x-api-key: YOUR_API_KEY"

{
  "success": true,
  "data": [
    {
      "content": {
        "id": "6841479",
        "text": "It's a time zone change on December 31st in Shanghai. See this page for details of 1927 in Shanghai. Basically at midnight at the end of 1927, the clocks went back 5 minutes and 52 seconds. So \"1927-12-31 23:54:08\" actually happened twice, and it looks like Java is parsing it as the later possible instant for that local date/time - hence the difference. Just another episode in the often weird and wonderful world of time zones. If rebuilt with version 2013a of TZDB , The original question would no longer demonstrate quite the same behaviour. In 2013a, the result would be 358 seconds, with a transition time of 23:54:03 instead of 23:54:08. I only noticed this because I'm collecting questions like this in Noda Time, in the form of unit tests ... The test has now been changed, but it just goes to show - not even historical data is safe. In TZDB 2014f , the time of the change has moved to 1900-12-31, and it's now a mere 343 second change (so the time between t and t+1 is 344 seconds,",
        "createdAt": "2011-07-27T08:31:10Z"
      },
      "ext": {
        "questionId": "6841333",
        "accepted": true
      },
      "engagement": {
        "likes": 11947
      },
      "author": {
        "id": "22656",
        "username": "Jon Skeet",
        "url": "https://stackoverflow.com/users/22656/jon-skeet",
        "avatarUrl": "https://www.gravatar.com/avatar/6d8ebb117e8d83d74ea95fbdd0f87e13?s=256&d=identicon&r=PG",
        "reputation": 1529880
      }
    },
    {
      "content": {
        "id": "8881376",
        "text": "Strings are immutable . That means once you've created the String , if another process can dump memory, there's no way (aside from reflection ) you can get rid of the data before garbage collection kicks in. With an array, you can explicitly wipe the data after you're done with it. You can overwrite the array with anything you like, and the password won't be present anywhere in the system, even before garbage collection. So yes, this is a security concern - but even using char[] only reduces the window of opportunity for an attacker, and it's only for this specific type of attack. As noted in the comments, it's possible that arrays being moved by the garbage collector will leave stray copies of the data in memory. I believe this is implementation-specific - the garbage collector may clear all memory as it goes, to avoid this sort of thing. Even if it does, there's still the time during which the char[] contains the actual characters as an attack window.",
        "createdAt": "2012-01-16T14:26:16Z"
      },
      "ext": {
        "questionId": "8881291",
        "accepted": true
      },
      "engagement": {
        "likes": 4769
      },
      "author": {
        "id": "22656",
        "username": "Jon Skeet",
        "url": "https://stackoverflow.com/users/22656/jon-skeet",
        "avatarUrl": "https://www.gravatar.com/avatar/6d8ebb117e8d83d74ea95fbdd0f87e13?s=256&d=identicon&r=PG",
        "reputation": 1529880
      }
    }
  ],
  "metadata": {
    "platform": "stackexchange",
    "endpoint": "user_answers",
    "cached": false,
    "stale": false,
    "age_s": 0,
    "fetched_at": "2026-01-01T12:00:00+00:00",
    "credits_charged": 5,
    "request_id": "7f3a9c2e5b1d4c8fa2e6d0b9c4f18e37"
  },
  "error": null
}