[fpc-pascal] Re: convert "epoch" to UTC

[Lukasz Sokol]

On 16/01/2012 03:09, waldo kitty wrote:
> 
> i'm needing to convert a "UTC epoch" date to a "standard time
> string"... by that, i mean that i want to get something like
> "2011-01-13 22:24:04" out of the "epoch" number 12013.9338171...
> 
> the above "epoch" number is (supposedly) built like this...
> 
> 12 == 2012 013 == 13th day of the year .9338171 * 24 == 22.4116104
> hours .4114104 * 60 == 24.696624 minutes
> 
> and here's where it breaks on me because
> 
> .696624 * 60 == 41.79744 seconds and that doesn't match the above
> time string showing 04 seconds... that time string was built from
> this "epoch" number (by another program) and i assume that it
> followed this published formula for this format (which is for
> satellite TLEs)...
> 
> so, my question is this... is there an existing FPC routine that will
> convert this (or a part of this) properly or do i need to play with
> something to get it right? it is obvious that this is not a "unix
> epoch"... i'm not sure how "normal" julian date epochs are
> represented...
> 
> i've looked through the docs on freepascal.org but none of them show
> an number with which to compare... there's no links pointing to a
> definition or example of a julian date or unix date or any such...
> 
> help! please :/
> 

See what Sven Barth said, for DateUtils
but also as for seconds mismatch, may it be due to leap seconds ?
http://en.wikipedia.org/wiki/Leap_second

which actually shows that current TAI - UTC = 34 seconds
(TAI = International Atomic Time) this actually is it: 41 - 34 = 7
(it's not 4 unfortunately but still close ?) 

(I guess satellite position is rather relative to TAI than UTC?)

(Or some float calculation bug like http://en.wikipedia.org/wiki/Pentium_FDIV_bug
 (or some float-to-string representation problem))
Lukasz