I am making a desktop based financial app in Ruby On Rails for my friend. I have a little concern over the system time I am using since time log being very important. What if system time changes because of some hardware issues. Should I go for time from internet or what are the alternates for this issue?
There are different kinds of time and time sources.
The local time, calculated with a time zone offset from system time. Local time is what users expect to see when they look at a clock. Unfortunately, time zones come with a lot of undesirable baggage. Local time is ambiguous if the time zone is not specified. Also, some time points are skipped or repeated when the clock moves between time zones, either because the system physically moves between time zones, or because of daylight saving time. While local time can be used for time stamps as long as the time zone is included, such a log may be unintuitive since the displayed times move back and forth.
The system time in UTC (confusingly called GMT in older APIs). System time is the calendar time the computer thinks we have, without any time zones applied. This gets rid of time zone problems, but isn't reliable for all purposes. In particular, users can set a specific system time. That means there might be sudden jumps backwards and forwards: this time is not monotonic.
For real-time systems, there are also some complications like one second of system time not necessarily being one second long. The system time may slow down if it is ahead of NTP time, or speed up if system time is behind. Some systems also require that every minute is exactly 60 seconds long. Such systems might distribute the effect of leap seconds over a whole day.
How system time is set depends. It might be initialized by user input or NTP or a hardware real time clock, might move forward through CPU interrupts or a hardware clock, and might be adjusted by user input or NTP.
AFAIK all modern consumer operating systems default to syncing their system time with NTP or through cellular service, either regularly or upon booting. All current consumer computer devices contain a battery-powered real time clock that will keep the time for multiple years even when the device is switched off.
A monotonic or steady time. This time never moves backwards and always moves at the same speed. A possible monotonic time implementation might count the seconds since the system booted, or since some other reference point. Since that reference point is arbitrary, an absolute time point cannot be related to calendar time. However, differences of monotonic time points can be used to measure durations correctly.
Your log should probably use system time. Yes, it's not guaranteed to be correct, but making it incorrect would generally involve active user interference. Trying to be better at time keeping than your operating system is going to be tough.
If you cannot trust the device's time source (e.g. because the time stamps are used to verify or execute contracts), then don't use that device. How this can be solved depends very much on the precise nature of your application, for example it might be best to maintain a trusted server that notarizes time stamps.
If your desired accuracy is only measured in miliseconds as for manual trading then use NTP, if you need micros or nanos as in algo-trading, then use Precision Time Protocol IEEE 1588.
I'd simply got for NTP time synchronization in your case. That will deviate only for a few seconds per day and per your comment you need only a precision at hour scale.
If you have a general logging facility you should use UTC for the time stamp. When reading the time stamp you can convert it to the local time for the time stamp as you like. When using other time systems you always run in danger of having duplicate times (the one hour overlap between summer and winter time as long as we do not get rid of this ridiculous procedure).