This is reasonable and not unsafe at all, particularly when it comes to timing things like exposure time with patients receiving radiation therapy.
However, we will be left wondering why treatment in the summer is more effective that treatment in the winter. Must be the nice weather.
I recommend using as little as date/day mechanics as you can get away with. Instead using a monotonic durations as much as you can [1].
If you continue to program with date/day mechanics you'll run into plenty of issues when users cross timezones or just set the time on their phone to a different one.
All the people pointing out the (genuine) problems with decimal time seem to be weirdly tolerant of the problems with our current system, which has much worse problems.
If you imagine the reverse situation, where society uses a decimal time, and some people are arguing we should switch to this system because despite all the things it makes worse and harder, it divides better and the numbers map somewhat (although imperfectly) to the actual time-of-day in various locales and (even less perfectly) to the kinds of things people might be doing at that time, everyone would think they were crazy.
If you want to prioritise ease of moving between the two systems, I'd suggest a normalised version of the new second. If you want to prioritise science, then something that makes a nice round number when giving the speed of light would be nice.
Either way the symbol for writing it should be different.
Even if those problems were harder to solve its far more valuable to have a single time for your meeting than multiple times (depending on the time zones of the participants). The pain of organising international meetings was one of the reasons I did this.
For more on the philosophy of this, I highly recommend Jenny Odell's Book, Saving Time. Note that she doesn't talk about the revolutionary calendar in it (to my memory) but touches on a lot of the realities of time and clocks themselves.
However, if using the calendar in day to day life, the Revised System is much easier.
To quote Wikipedia:
leap years being every year divisible by 4, except years divisible by 100 and not by 400. Years divisible by 4000 would also be ordinary years. This calendar also has the benefit that every year in the third century of the Republican Era (1992–2091) begins on 22 September.
(The article is still relevant with metric time/weeks)
> Does that mean I can call him? I don't know.
About the non timezone version but skates over the fact that he doesn't know the answer in the timezone version either. He says "Google tells me..." well sure, if you're allowed to use Google you could just have easily have asked "what are typical daylight/waking hours in x location?" This is much better anyway since in some countries culturally you siesta in the early afternoon (don't call please) and stay up later.
Anyway there is something of a genuine problem here (although I don't consider it serious) and I'd solve it by drawing the world on the side of the clock and allowing you to rotate the face by selecting a place on the map.
My version also removes timezones. The numeric time is the same whereever you are in the world, but the display changes based on your location so that local solar midday is straight up on the clock face and local solar midnight is straight down on the clock face.
I used to have it attach to your google calendar and draw meetings onto the clock face too, but I think in the last 11 years the google calendar api has changed and I haven't updated it.
Obviously once you have metric time, you need a metric week too, so I have new week days: nullday, unday, duoday, triday, quadday, hexday heptday, octday and nonday. There's no need for months anymore, I just number the weeks.