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?

  • Let me be sure I'm capturing your real requirements: You need confidence that the system clock isn't mis configured before you start loging time stamped events? – candied_orange Dec 10 '16 at 11:43
  • Time is such an elusive thing. We take the approach of trusting the system time, but we also actively monitor that and are notified if it is a second out from NTP sources. If you can't trust your system time, does your language have an API to query some NTP sources directly, to occasionally compare to the system time and report the problem within the application? Kind of a built-in time monitoring? rubygems.org/gems/net-ntp/versions/2.1.3 – Dan Armstrong Dec 10 '16 at 11:49
  • Also you need to state how precise you time needs to be. Does it care for the extra second that's added every few years? – qwerty_so Dec 10 '16 at 12:00
  • 1
    What are the consequences if you do not have exact time? – kdgregory Dec 10 '16 at 13:11
  • 4
    @InQusitive you say the time log will be very important. Why? We need to know what this log has to be able to stand up to. Do you need to mesure dates? time of day? seconds between events? Stand up in a court of law? Tell us the storys that make this log important. – candied_orange Dec 10 '16 at 13:38

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.

  • Yes, your second last paragraph is what I was thinking. I will go with the user assurance that they will never change system time. – InQusitive Dec 10 '16 at 13:35
  • 1
    Using system time makes you dependent on summer/winter time. Logging should always use UTC to be reliable. You mix system time with UTC. That's no good. – qwerty_so Dec 10 '16 at 13:36
  • @ThomasKilian I tend to agree, and my answer uses “system time” in the meaning “the UTC time according to this computer”, in contrast to local time which is the system time translated into some time zone. But time zones don't really matter as long as the TZ offset is included in the timestamp, e.g. 2016-12-10T15:07:46+0100. In countries further away from the null meridian than Germany, I'd understand why local time would be preferred over UTC, otherwise the date would increment during the work day, which is potentially confusing. – amon Dec 10 '16 at 14:10
  • I'd separate system time from UTC since the system time is (hence the name) the time you use on your system. That might be UTC, but can as well be some local time or even any remote time if you have enterprise systems configured that way. – qwerty_so Dec 10 '16 at 14:34

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).

  • I never heard summer/winter time here in India. I will read about it. – InQusitive Dec 10 '16 at 14:00
  • @InQusitive We call it daylight savings. It's not something you want complicating your logs. – candied_orange Dec 10 '16 at 14:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.