Dates sort wrong, group wrong, and diff wrong when they are strings. Parse them into real date objects once, and the comparisons become correct. Time zones are the second trap, and they are the one that bites across a whole team.
About 1 min of reading
Sort dates correctly and derive a month key.
Show the string sort trap
Before you run it, say out loud what it will print. Then open the answer.
Fix it with zero padding
Before you run it, say out loud what it will print. Then open the answer.
Read the first example one line at a time. A line that prints shows what appears on screen; the rest set things up quietly.
03/04/2026 is the third of April or the fourth of March. Nothing in the string resolves it. Standardise on ISO 8601 (2026-04-03) at the boundary where the data is produced, and record which format was assumed if you cannot.
'This month' means different things at the start and end of a month, and a period that crosses a DST change is not a whole number of hours. Use period boundaries computed from dates, not hour counts.
datetime.strptime(s, '%Y-%m-%d') or new Date(...) turns text into a value with real ordering. Sorting ISO 8601 strings happens to work, and that coincidence is why people leave them as strings. It fails the moment the format varies.
Keep one representation internally, UTC, and convert only at display time. Mixing local and UTC in the same column produces timestamps that are individually valid and collectively wrong.
Ask for the month or the week, not the day, by deriving the key from the date: r['2026-10'] or an ISO week. Grouping on the raw timestamp gives one group per timestamp and a table nobody can read.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.