Why use non-standard data types (datetime, user, geopt) in databases?

Question

Google Workspace

Started using Google App Engine. They have non-standard Properties (data types) in the DataStore (DB) - datetime, user, geopt. I have not noticed any benefit from them (yet), but there are problems, for example, serialization to JSON. Of course, this is solved by writing your own Encoder. But still ... If I now re-created the table (there it is called Kind), then most likely instead of datetime I used just integer (unixtime), instead of user - string (nickname, and then I received the user object by making a request modulo users), instead of geopt - two columns latitude and longitude. So it turns out less unnecessary body movements later, with the direct use of these data. Because from unixtime and in Python, and in JS and in Africa, you can get datetime.
But more familiar DBMS like Postgresql also have similar types. Does it make sense?

Answer 1

The point is that it opens up the ability to perform server-side data transformations without prefetching. For example, you can quickly filter records that have timestamps related to a specific day of the week (for all time), aggregate data in other fields, and return the result as a single record. With a date in unixtime in the integer field, you would either have to pull out the entire table on the client and count there, or write a huge bike on stored procedures on the server (and still it will be slower than built-in functions, which even provide optimization when searching by index ).
With geographic coordinates, it's still more interesting. How do you imagine the task of finding/selecting all objects within a given radius from a given point, if the coordinates in the table are given by latitude and longitude in integer fields? On a flat surface, this is still relatively easy (all the same, filtering will go in two stages (with a subquery, for example), and at the first stage a lot of unnecessary will be selected, since integer indexes cannot filter on the fly by calculated expressions). But what if the search/filtering radius is measured in hundreds and thousands of kilometers? The ambush here is that the Earth is not flat ... And for geographic coordinates (as a special data type) there is a special function for this, in which all this has already been provided and decided, and there is also a special type of index for this data type,