"if say computer languages had declarative statements and underlying mechanisms to separate internal and external clocks"
Well, we actually do have those things. You're pretty much describing how the unix time APIs work today.
The internal unix clock is kept as a "time_t", "struct timeval", or "struct timespec", which is seconds, usec, or nsec since an epoch. This is largely insulated from the geopolitical nonsense -- though it is imperfect with respect to leap seconds and it should have been defined as TAI. This is specified in sys/time.h on linux . These are further separated into clocks like CLOCK_REALTIME and CLOCK_MONOTONIC, which track adjusted actual time (updated by ntp), and elapsed relative time respectively.
The "external clocks" as you call them are specified by the time.h functions like "ctime" or "localtime." These functions take the above internal clocks and apply timezone data to localize time to a specific area on earth.
"If one thinks about it this isn't as a preposterous idea as it may seem as the whole notion of relative time naturally falls out of Relativity/Spacetime."
Right, but we do this already. There's no such thing as a clock without a frame of reference though, so there will always be some special location in space/time which is the perspective of the system clock.
"Making computers and compter languages inherently aware of the fact would likely bring benefits. "
We already have reaped these benefits! The existing problems center around stuff like:
* Figuring out who's a correct relative authority for a given place on earth
* Communicating updates (and, correspondingly, guarding against bad updates)
* Figuring out how to keep various autonomous systems consistent
* Helping software developers understand these inherent complexities in timekeeping -- because I guarantee your average software developer is largely unaware that all these distinctions already exist.