You've caught a common bug (IME) in the implementation of these relative time/date stamps -- at a step-change in the precision you lose a lot of information due to rounding, and the rounding is always down.
It's common (I assume due to a built in library) on Android apps to get "59 minutes ago" (more precise than needed) then "1 hour ago" displayed for the next 60 minutes (less precision than needed). If it was up to me I'd code your example to give "23 months ago". That's not to say I'm right though. Another option might be to give "just under 2 years ago" or "about 2 years ago".
I think it would be better to have something along the lines of 1,2,3,4,5,10 minutes followed by ¼, ½, ¾ hour up to say 3¾ hours, then integer hours up to ~48, days to 8, weeks to 5, months to 23 and finally years. This would make the loss of precision less sudden as the maximum ratio is ~1.5* rather than 2*.
As for UX reasoning, I would have thought that time zones would come in to it: throw the time posted and the user's time, both with time zones, at your standard date/time library to get a difference, then round. The user doesn't have to care about timezones then. Of course you could convert everything to the user's timezone (I've assumed you know it already) and present that but it's not necessarily helpful. Imagine a headline and timestamp "News just in: Mass pile-up in the morning rush-hour. 16:50 today". In fact Strava does something similarly daft - someone I follow is in New Zealand and I'm in the UK. Their morning commute shows up in my feed tagged as "today" when it should be "tomorrow" - and would be if dates were compared naively.