Skip to main content
added 39 characters in body
Source Link
Brock Adams
  • 13k
  • 5
  • 39
  • 64

This is probably a variation of this bug and a variation or repeat of this bug that was partially fixed (once upon a time).

Anyway, the timeline does show all your events as can be seen with this query:
    /2.2/users/4751173/timeline?fromdate=1563667200&site=stackoverflow
where 1563667200 is midnight on July 21st, 2019.

The problem is that creation_date is (still/again) all kinds of FUBAR and does not refer to the actual time of the event.

For example, the above query returns an item:

{
  "post_id":        2818028,
  "user_id":        4751173,
  "timeline_type": "revision",
  "post_type":      "answer",
  "creation_date":  1273661209,
  "detail":         "broken image fixed (click 'side-by-side' to see...",
  "title":          "Equivalent of Bloch's Effective Java for C#"
},

where creation_date is 1273661209.
1273661209 corresponds to 2010-05-12 10:46:49 UTC which is the time that the answer was created, NOT when the edit was made. (And also well before the fromdate.)

This, of course, makes little sense and is not useful for the timeline.

This is probably a variation of this bug and a variation or repeat of this bug that was partially fixed (once upon a time).

Anyway, the timeline does show all your events as can be seen with this query:
    /2.2/users/4751173/timeline?fromdate=1563667200&site=stackoverflow
where 1563667200 is midnight on July 21st, 2019.

The problem is that creation_date is (still/again) all kinds of FUBAR and does not refer to the actual time of the event.

For example, the above query returns an item:

{
  "post_id":        2818028,
  "user_id":        4751173,
  "timeline_type": "revision",
  "post_type":      "answer",
  "creation_date":  1273661209,
  "detail":         "broken image fixed (click 'side-by-side' to see...",
  "title":          "Equivalent of Bloch's Effective Java for C#"
},

where creation_date is 1273661209.
1273661209 corresponds to 2010-05-12 10:46:49 UTC which is the time that the answer was created, NOT when the edit was made.

This, of course, makes little sense and is not useful for the timeline.

This is probably a variation of this bug and a variation or repeat of this bug that was partially fixed (once upon a time).

Anyway, the timeline does show all your events as can be seen with this query:
    /2.2/users/4751173/timeline?fromdate=1563667200&site=stackoverflow
where 1563667200 is midnight on July 21st, 2019.

The problem is that creation_date is (still/again) all kinds of FUBAR and does not refer to the actual time of the event.

For example, the above query returns an item:

{
  "post_id":        2818028,
  "user_id":        4751173,
  "timeline_type": "revision",
  "post_type":      "answer",
  "creation_date":  1273661209,
  "detail":         "broken image fixed (click 'side-by-side' to see...",
  "title":          "Equivalent of Bloch's Effective Java for C#"
},

where creation_date is 1273661209.
1273661209 corresponds to 2010-05-12 10:46:49 UTC which is the time that the answer was created, NOT when the edit was made. (And also well before the fromdate.)

This, of course, makes little sense and is not useful for the timeline.

Source Link
Brock Adams
  • 13k
  • 5
  • 39
  • 64

This is probably a variation of this bug and a variation or repeat of this bug that was partially fixed (once upon a time).

Anyway, the timeline does show all your events as can be seen with this query:
    /2.2/users/4751173/timeline?fromdate=1563667200&site=stackoverflow
where 1563667200 is midnight on July 21st, 2019.

The problem is that creation_date is (still/again) all kinds of FUBAR and does not refer to the actual time of the event.

For example, the above query returns an item:

{
  "post_id":        2818028,
  "user_id":        4751173,
  "timeline_type": "revision",
  "post_type":      "answer",
  "creation_date":  1273661209,
  "detail":         "broken image fixed (click 'side-by-side' to see...",
  "title":          "Equivalent of Bloch's Effective Java for C#"
},

where creation_date is 1273661209.
1273661209 corresponds to 2010-05-12 10:46:49 UTC which is the time that the answer was created, NOT when the edit was made.

This, of course, makes little sense and is not useful for the timeline.