Calendar appointments are a good example where a timestamp without a timezone (java's Instant) is appropriate. But a birthday doesn't have a time, so you would want to use LocalDate (a date without a time and timezone) for that.

In 99% of the cases you only really want to involve timezones when presenting something to the user or taking input from them.

So you would create your calendar event by entering "9am, timezone X", and the app would most probably just apply that offset and store that as a timestamp. But if it's an all-day event... I should probably take a look at android's calendar content provider.

I think there is a simple reason for not using unsigned integers. If you use an unsigned integer and get an overflow it's not immediately obvious or even possible to see from the value alone. If you use a signed integer, any negative number means there was a mistake somewhere. That is easier to check for. But that said, they should store it as something like Unix time, even for a calendar. Otherwise sending appointments between timezones need conversions which is notoriously hard to get right. Ideally it'll be stored as local timestamp with timezone offset at the end. That way all information is stored, and in parallel it can have a unix time for reasons of efficiency.

or put the month first (but of course that ruins easy sortability)

time_t solved the 2038 problem a long time ago