Unix to standard time conversion.

[Stiganator]

I have the time in seconds since 1970, but how do I convert that to MM/DD/YYYY TT:TT?

 

[n0cmonkey]

How does unix do it?

 

[DnetMHZ]

Here you go..

 

[n0cmonkey]

It looks like ctime(3) is what you might want to look at (if DnetMHZ's suggestion isn't quite what you need).

 

[Jzero]

This is a very elementary conversion problem. I'll give you a hint: 31557600 seconds in a 365.25-day year.

 

[DnetMHZ]

I guess I should have asked if you needed to do this only once or programmatically.

 

[n0cmonkey]

Originally posted by: DnetMHZ
I guess I should have asked if you needed to do this only once or programmatically.

Your post was more helpful than my first one.

I was just busy looking for the correct manpage to reference.

 

[Armitage]

Originally posted by: Jzero
This is a very elementary conversion problem. I'll give you a hint: 31557600 seconds in a 365.25-day year.

It's not quite so elementary when you roll leap years, leap seconds, time zones, daylight savings time, etc. into it.

Time keeping is a messy business - best to use the library functions (ctime, asctime, localtime, gmtime, etc.)

 

[Jzero]

Originally posted by: Armitage

Originally posted by: Jzero
This is a very elementary conversion problem. I'll give you a hint: 31557600 seconds in a 365.25-day year.

It's not quite so elementary when you roll leap years, leap seconds, time zones, daylight savings time, etc. into it.

Time keeping is a messy business - best to use the library functions (ctime, asctime, localtime, gmtime, etc.)

Yes, you can complicate it as much as you wish, but converting number seconds "after the epoch" to local time is a rudimentary factor-label conversion.

You will obviously assume your own local time zone and DST rules.

It's trivial to figure out how many leap years have occurred since 1970.

Leap seconds, which are added on an as-needed basis, need only be factored in if extreme precision is required, but it is certainly easy enough to look up how many leap seconds have been inserted between 1970 and now (22, all positive).

This isn't timekeeping, it's merely converting measurements.

 

[Armitage]

Originally posted by: Jzero

Originally posted by: Armitage

Originally posted by: Jzero
This is a very elementary conversion problem. I'll give you a hint: 31557600 seconds in a 365.25-day year.

It's not quite so elementary when you roll leap years, leap seconds, time zones, daylight savings time, etc. into it.

Time keeping is a messy business - best to use the library functions (ctime, asctime, localtime, gmtime, etc.)

Yes, you can complicate it as much as you wish, but converting number seconds "after the epoch" to local time is a rudimentary factor-label conversion.

You will obviously assume your own local time zone and DST rules.

It's trivial to figure out how many leap years have occurred since 1970.

Leap seconds, which are added on an as-needed basis, need only be factored in if extreme precision is required, but it is certainly easy enough to look up how many leap seconds have been inserted between 1970 and now (22, all positive).

This isn't timekeeping, it's merely converting measurements.

It's not how many leap years or leap second have occured between 1970 and now, but how many have occured between 1970, and the epoch in question. In any case, my point is that there are alot of things to take into account, including the time zone & daylight savings time of the various locales where the program may be used, keeping up with leap seconds as they are added ad hoc, etc.

It's not all that hard, but there's alot of room to scew it up, so why wouldn't you use the standard library functions?

 

[Jzero]

Originally posted by: Armitage
It's not how many leap years or leap second have occured between 1970 and now, but how many have occured between 1970, and the epoch in question.

Re-read the question. Are you familiar with Unix "epoch time?"

You have the current time in number of seconds since January 1, 1970. That date IS the epoch for this particular system, which we can assume to be some unix-like OS. Convert that to "standard" time format.

Issue the command date +%s and you will get something like 1117202362 which represents the number of seconds in local system time (which is why time zone and DST are of no concern) that have passed since January 1, 1970.

It's not all that hard, but there's alot of room to scew it up, so why wouldn't you use the standard library functions?

Well, basically because I have never seen this question asked outside of beginning programming classes where one is asked to write a program to convert "epoch" time to "normal" time WITHOUT using existing functions. There's plenty of existing methods to make the conversion, but I'm assuming if the question is being asked, it's because those existing methods are off limits, but perhaps I am assuming too much

 

[Armitage]

Originally posted by: Jzero

Originally posted by: Armitage
It's not how many leap years or leap second have occured between 1970 and now, but how many have occured between 1970, and the epoch in question.

Re-read the question. Are you familiar with Unix "epoch time?"

You have the current time in number of seconds since January 1, 1970. That date IS the epoch for this particular system, which we can assume to be some unix-like OS. Convert that to "standard" time format.

Issue the command date +%s and you will get something like 1117202362 which represents the number of seconds in local system time (which is why time zone and DST are of no concern) that have passed since January 1, 1970.

Yep I'm familiar with it. But in fact, date +%s returns seconds since Jan 1 1970 UTC, so you do need timezone & DST information to get the current local time.

In any case, let's try an example:

% date
Fri May 27 09:02:57 MDT 2005

% date +%s
1117206177

1117206177/31557600 = 35.402127

Year = 1970 + int(35.402127) = 2005 - so far so good
Day of Year = (35.402127 - int(35.402127))*365.25 = 146.877049

Today is day 147, counting from Jan 1 as day 1. This algorithm will give 0 for seconds during Jan 1, so we add 1 and all is well

Hour = (146.877049 - int(146.877049)) = 21.049167

This is interesting - 6 hours (1/4 day) off from UTC. Sounds like we're not handling something right with regard to leap years.

I can get the right UTC hour by using a 365 day year for everything (vs. 365.25). Then you just subtract the number of leap days since 1970 (9) to get the correct day of year. I'm sure there are other ways to handle it.

Minutes = (21.049167 - int(21.049167))*60 = 2.950000 - Ok

Seconds = (2.950000 - int(2.950000))*60 = 57 - 0k - looks like leap seconds are already rolled in there. They become an issue in my work when you have an analysis that crosses the addition of a leap second. In my work, 1 second = 7 Km

It's not all that hard, but there's alot of room to scew it up, so why wouldn't you use the standard library functions?

Well, basically because I have never seen this question asked outside of beginning programming classes where one is asked to write a program to convert "epoch" time to "normal" time WITHOUT using existing functions. There's plenty of existing methods to make the conversion, but I'm assuming if the question is being asked, it's because those existing methods are off limits, but perhaps I am assuming too much

I think you're assuming to much - I think he was just asking what the existing functions were, not how to roll his own.

 

[n0cmonkey]

Originally posted by: Jzero

Issue the command date +%s and you will get something like 1117202362 which represents the number of seconds in local system time (which is why time zone and DST are of no concern) that have passed since January 1, 1970.

Shouldn't that still give you the wrong time without applying timezone, since unix systems are traditionally set to GMT in hardware?

 

[Jzero]

Originally posted by: Armitage
Yep I'm familiar with it. But in fact, date +%s returns seconds since Jan 1 1970 UTC, so you do need timezone & DST information to get the current local time.

You and n0cmonkey are indeed correct that it is UTC/GMT and not local time.

In any case, let's try an example...

It is probably most straightforward to just use 365 day years and add a day for each leap year since 1970.
Anyway, does this mean we are in agreement that it is just a unit conversion not much different from converting inches to miles?

I think you're assuming to much - I think he was just asking what the existing functions were, not how to roll his own.

You may be right. The OP didn't give us much to go by.

 

[Armitage]

Originally posted by: Jzero

Originally posted by: Armitage
Yep I'm familiar with it. But in fact, date +%s returns seconds since Jan 1 1970 UTC, so you do need timezone & DST information to get the current local time.

You and n0cmonkey are indeed correct that it is UTC/GMT and not local time.

In any case, let's try an example...

It is probably most straightforward to just use 365 day years and add a day for each leap year since 1970.
Anyway, does this mean we are in agreement that it is just a unit conversion not much different from converting inches to miles?

Well, it is a bit different - you don't have to take into account whether you're on the east coast vs. west coast, or summer vs. winter, how many leap years there have been since 1970, etc., to do inches to miles.

But in any case, I think we've about beaten it to death

I think you're assuming to much - I think he was just asking what the existing functions were, not how to roll his own.

You may be right. The OP didn't give us much to go by.