There's a difference between timestamps and dates. For instance Christmas Day is on 2022-12-25, but it doesn't have any particular time stamp as that depends on which time zone you are in.
If you are making a calendar app, you want to store dates and not timestamps as, e.g. if I have a flight to another country then have an appointment at 9am, that 9am should be in the time zone of wherever I am physically present, which the calendar doesn't necessarily know.
Storing as an integer is compact and allows for easy comparison. It's a clever hack, but they should have used 64 bit, or at least a u32!
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.
Not storing absolute times is a disaster. If it's seemingly working now it's only because your use case apparently doesn't include anything cross-timezone.
Referring to something like "Christmas day" as timezoneless doesn't help either. Anyone who celebrates it celebrates it in a timezone. Christmas Day EST is a different event than Christmas Day CEST. Trying to represent them as the same event will only lead to heartbreak.
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.
If you are making a calendar app, you want to store dates and not timestamps as, e.g. if I have a flight to another country then have an appointment at 9am, that 9am should be in the time zone of wherever I am physically present, which the calendar doesn't necessarily know.
Storing as an integer is compact and allows for easy comparison. It's a clever hack, but they should have used 64 bit, or at least a u32!