1

I've got the unix time since January 1st 1970 (E.G 1531074816) from my GPS module, how do I convert this into a readable format? I only need to get the current hour, minutes and seconds. I'm not worried about the day or date. I'm also using C. Thanks.

Joe
  • 37
  • 8
  • 3
    Call [`localtime`](https://linux.die.net/man/3/localtime), or [`gmtime`](https://linux.die.net/man/3/gmtime) if you don't want conversion to your local time zone. Then print fields from the returned `struct tm *` directly, or call [`strftime`](https://linux.die.net/man/3/strftime) to do it for you. – Steve Summit Jul 08 '18 at 18:55
  • Can't find a dup on SO, but see http://c-faq.com/lib/curtime.html . – Steve Summit Jul 08 '18 at 19:06
  • 2
    You'll need to worry about whether the value you got incorporates leap seconds and whether the library you use handles leap seconds. But apart from that (not entirely trivial) issue, `localtime()` and `gmtime()` are the answer. – Jonathan Leffler Jul 08 '18 at 19:46
  • @JonathanLeffler Unless you know something I don't, I would pretty confidently assure any ordinary Unix/Linux application programmer that they do *not* need to worry about that -- it's virtually guaranteed that (a) the time_t values they have do not incorporate leap seconds and (b) the library they're using does not handle leap seconds, either. (So they only need to worry if they need proper leap second handling, in which case they're probably out of luck.) – Steve Summit Jul 09 '18 at 01:04
  • @SteveSummit : the information comes from a GPS receiver. Most other sources I’d agree with you about. GPS could be different. – Jonathan Leffler Jul 09 '18 at 01:05
  • 1
    @JonathanLeffler Ah, good point. I was wondering about that, too. I've never heard of a GPS receiver or library that outputs `time_t` values. GPS receivers do typically perform [GPStime](https://en.wikipedia.org/wiki/Global_Positioning_System#Timekeeping) --> UTC conversion before delivering time to the user, but obviously `time_t` would be a poor choice for this, since it can't represent true UTC properly. – Steve Summit Jul 09 '18 at 01:11

3 Answers3

2

use gmtime

#include <stdio.h>
#include <time.h>

int main()
{
    static const time_t unixtimestamp = 1230728833;
    struct tm *tmp = gmtime(&unixtimestamp);


    printf("%02d:%02d:%02d\n", tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
    return 0;
}
ergesto
  • 367
  • 1
  • 8
1

As Steve Summit says, fastest and easiest is to just use localtime():

void show_time (time_t time_from_gps)
{
    struct tm *timmay;

    timmay = localtime(&time_from_gps);
    printf("%02d:%02d:%02d\n", timmay->tm_hour, timmay->tm_min, timmay->tm_sec);
}

You really don't want to try to roll-your-own time procedures. Time is complicated and life is a lot easier if you let libc handle the complexity for you.

Steve Summit
  • 45,437
  • 7
  • 70
  • 103
One Guy Hacking
  • 1,176
  • 11
  • 16
0

If you don't want to use any third party code you can follow these: You should first get rid of all days since 1970 with the help of modulo operator. Then you will have seconds passed since the beginning of current day. You can calculate how many hours are passes using this number. With the same approach you can get minutes and seconds.

If your timestamp is in seconds. Then:

long currentTime;
long oneDay = 24L * 60 * 60;
long oneHour = 60 * 60;
long oneMinute = 60;

long currentDaySeconds = currentTime % oneDay;
long currentHour = currentDaySeconds / oneMinute;
long currentMinute = (currentDaySeconds % oneHour) / oneMinute;
long currentSeconds = currentDaySeconds % oneMinute;
Arda Kara
  • 501
  • 6
  • 24
  • This may be good enough for ranch work, but it's not accurate as you do not factor in leap seconds. You will be off by the number of leap seconds since the epoch--a difference of 37 seconds as of this writing – One Guy Hacking Jul 08 '18 at 19:16
  • 1
    @Jabberwock Not true, actually. POSIX says that Unix `time_t` values do *not* account for leap seconds. Code like this is guaranteed to work. – Steve Summit Jul 08 '18 at 19:26
  • @Steve You are absolutely correct--I had no idea. Thanks. – One Guy Hacking Jul 08 '18 at 19:35
  • 1
    Both are wrong... leap seconds are inserted in UTC to compensate earth rotation (basis of UTC) against deviation of TAI (atomic time) Leap seconds are somewhat umpredictable and are announced when they should be inserted. They modify the UTC scale, but POSIX says (correctly) that POSIX don't take that into account. So the unix internal clock has to be corrected manually to compensate the leap second insertion. – Luis Colorado Jul 10 '18 at 20:07