1

I been comparing the equality of the 2 time one that is taken from loacal machine and one from server

time_t local= kernel()->time_now()

this time_now() do return time_t and uses normal way to get sys time

time_t remote =fs->ctime()

getting the creation time of a directory..then when I do local==remote it fails since i got some minute difference between the client and server then I synced them even close to the seconds.After that it passes, yet sometime it fails, really unpredictable my question would it be OK to use == over time_t or I have to use some std function I saw difftime() will it be ok for equality check because I need bool as a result

stenliis
  • 337
  • 8
  • 22
RaGa__M
  • 2,550
  • 1
  • 23
  • 44
  • 1
    time_t is just a number. so in general it's ok to compare them with `==` Vou just have to take into account that both server/client need to be time synchronized. Timezones can also mess stuff up. – Hayt Sep 13 '16 at 08:02

2 Answers2

1

You should compare the difference between those times (calculated with difftime()) to an acceptable error margin if they can slightly differ.

You get your bool like this:

(fabs(difftime(remote, local)) < epsilon)

fabs is to get the absolute value of the double returned by difftime (which means that if it's a negative value, it will become positive) which you then compare to epsilon which is your accepted divergence

sokkyoku
  • 2,161
  • 1
  • 20
  • 22
-1

Hey time_t is long int in 64 bit machines else it is long long int (varies in system..it maybe long also) so yes you can compare. But it is always better to use difftime() to accurate results.

Now as difftime() knows what this time_t means( if it is based on some year month day or if the bits of time_t represent something internally lie that etc then difftime() passes Which the - cannot. ) [ if time_t based on the system doesn't specify the it to be difference of time from certain point then we cant use time_t in subtraction rather it is clearly advisable to use the difftime() to get predictable results on such cases]

Also difftime() is guaranteed to work bu subtract may yield wrong result. Also the result returned by difftime() is double unlike - which yields long int which may yield very large value not possible to store in time_t.

user2736738
  • 30,591
  • 5
  • 42
  • 56
  • "can give you year month day etc". No it can't. `difftime()` returns a `double`, not a `time_t`. `time_t` can give you that information but `difftime()` returns the difference in seconds and thats it – sokkyoku Sep 13 '16 at 08:09
  • @sokkyoku>; No what i mean to say is...if some format is internally there then difftimes passes subtarctin fails. – user2736738 Sep 13 '16 at 08:11
  • @sokkyoku>: please check my answer..if you feel like anything wrong or not clear..please let me know. Thanks for pointing out the unclear statements. – user2736738 Sep 13 '16 at 08:19
  • You can look through the source code of `difftime()` (https://fossies.org/dox/glibc-2.24/difftime_8c_source.html) all it does is subtract the second one from the first. – sokkyoku Sep 13 '16 at 08:20
  • 1
    Yes sokkyoku that's what it does..in most system,subtraction and difftime() give same result but only difftime() is guaranteed to work correctly on all systems. – user2736738 Sep 13 '16 at 08:22
  • yes it can ..suppose on some system the programmer sets it to be unsigned int and then someone does this like ` 1000 years earliers time - todays times` it will be negative but as it is unsigned it will give a large unpredicatble value now you will say how come long long or long int do that and that is system dependent ...that's what i am saying... `difftime()` take care of all this..you dont have to worry about all this details if you use `difftime()` always. – user2736738 Sep 13 '16 at 08:24
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/123217/discussion-between-sokkyoku-and-coderredoc). – sokkyoku Sep 13 '16 at 08:25
  • It is unclear how the different parts of your answer relate to relevant standards (C, POSIX). There is no reference to which standard mandates the type . No reference to whether the encoding of the value is mandated by said standards. – Klas Lindbäck Sep 13 '16 at 08:29
  • Hey @KlasLindbäck ah I just said generic things... the whole idea is that system dependent implementations must be manipulated by system dependent functions only ..it yields safe result everytime. – user2736738 Sep 13 '16 at 08:31
  • Btw whoever gave that downvote....kindly let me know my errors..I will try to give correct answers. – user2736738 Sep 13 '16 at 08:31
  • Users who downvote atleast let us know the reason for downvote.. Ultimately a good correct answer is needed. Let me know that kindly. Otherwise it doesn't help anybody. – user2736738 Sep 13 '16 at 08:39
  • @coderredoc I'm just pointing out what's lacking to make your answer a great answer. Right now, it is passable, since it points out that `difftime` is the most portable way forward. Unfortunately, since the rest is not backed by references, the value it adds is.... not much. It is up to you whether you have the time and energy to improve it. – Klas Lindbäck Sep 13 '16 at 09:07
  • I put the downvote on your answer because it's confusing. What you're saying boils down to "systems implement `time_t` differently so you should use `difftime()` to compare them as it's guaranteed to work" and not much else. I think the answer would gain by being shortened, it also doesn't resolve the actual problem OP is facing which is that the times compared aren't always identical when they should be. – sokkyoku Sep 13 '16 at 09:21