Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2012-01

convert "epoch" to UTC

16 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

waldo kitty

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 :/

Sven Barth
"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...

Show quoted text 11 lines
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...

I don't know whether your format is really a Julian or Unix time (for Julian it looks too low), but can take a look at unit "DateUtils" of which the documentation is here:
http://www.freepascal.org/docs-html/rtl/dateutils/index-5.html Especially you can try JulianToDateTime and UnixToDateTime. Both return a TDateTime which you can convert to a string using FormatDateTime ( http://www.freepascal.org/docs-html/rtl/sysutils/datetimetostring.html ) or DateTimeToStr (
http://www.freepascal.org/docs-html/rtl/sysutils/datetimetostr.html).

Regards,
Sven

Lukasz Sokol
to waldo kitty: i'm needing to convert a "UTC epoch" date to a "standard time string"... by that, i mean…
waldo kitty wrote 30 lines
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

Jeff Wormsley
to Lukasz Sokol

I went here:

http://www.satellite-calculations.com/TLETracker/SatTracker.htm

It had the TLE for Galaxy 15 as follows:

GALAXY 15
1 28884U 05041A 10133.62484064 .00000085 00000-0 10000-3 0 8291 2 28884 000.1391 078.0756 0002640 331.8937 274.1784 01.00285599 16790

And did these calculations (using Calc on Ubuntu)

10133.62484064 - Thu May 13 2010 10:59:46 GMT-0400 (EDT) = Thu May 13 2010 14:59:46 GMT

10 - 2010
133 - 133rd day (assume that's Thu May 13 - didn't check)

0.62484064 * 24 = 14.99617536
0.99617536 * 60 = 59.7705216
0.7705216 * 60 = 46.231296

Seems ok to me...

Replacing there time stamp in that web site with your example gives the same answer you got. Either that web site is wrong, too, or your example was wrong.

Jeff.

waldo kitty
to Sven Barth: by that, i mean that i want to get something like "2011-01-13 22:24:04" out of the…
Sven Barth wrote 6 lines
Am 16.01.2012 04:10 schrieb "waldo kitty" > > > 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...

TYPO ALERT! that should be .93338171... with the additional '3' in there, the final value for the seconds is 4... long day, tired eyes and dirty glasses :/

[TRIM]

Show quoted text 11 lines
> 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 <http://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... I don't know whether your format is really a Julian or Unix time (for Julian it looks too low),

it is actually one of the "julian" ones... it is the "julian day of year" format... at least that's what i believe it is called...

but can take a look at unit "DateUtils" of which the documentation is here: http://www.freepascal.org/docs-html/rtl/dateutils/index-5.html

yes, i had been all in there... that's where i was expecting to see an example that actually contained a number that would be converted to a date so that one might work out the math manually if desired... without a number, i had nothing to compare what i have with to see if it was even close...

Especially you can try JulianToDateTime and UnixToDateTime. Both return a TDateTime which you can convert to a string using FormatDateTime ( http://www.freepascal.org/docs-html/rtl/sysutils/datetimetostring.html ) or DateTimeToStr ( http://www.freepascal.org/docs-html/rtl/sysutils/datetimetostr.html ).

i think i might be able to do something with the JulianToDateTime once i get the base year portion converted to a true julian... i spotted some C# code while doing a bit of research earlier (see below)... it appears to convert the year to a julian year and then add the decimal day portion... this should then be a proper julian date which i should be able to handle ;)

[---- WARNING: C# code follows ----]
double getJulianDay_Year(int year)
{
     double dYear = year - 1;
     double A = Math.Floor(dYear / 100);
     double B = 2 - A + Math.Floor(A / 4);
     //The use of 30.600000000000001 is to correct for floating point rounding
problems
     double dResult = Math.Floor(365.25 * dYear) + 1721422.9 + B;
     return dResult;
}
double getJulianDay_SatEpoch(int year, double dSatelliteEpoch)
{
     //Tidy up the year and put it into the correct century
     year = year % 100;
     if (year < 57) year += 2000;
     else year += 1900;
     double dResult = getJulianDay_Year(year);
     dResult += dSatelliteEpoch;
     return dResult;

}
[---- end of C# code ----]

looks like it should be easy to convert to pascal, too ;) just gotta find out what that "floor" routine does ;)

waldo kitty
to Jeff Wormsley: I went here: http://www.satellite-calculations.com/TLETracker/SatTracker.htm It had the…
Jeff Wormsley wrote

funny thing, that! when i woke up this morning and went researching, that was the first site that uncle google showed me, too :lol:

Show quoted text 5 lines
It had the TLE for Galaxy 15 as follows: GALAXY 15 1 28884U 05041A 10133.62484064 .00000085 00000-0 10000-3 0 8291 2 28884 000.1391 078.0756 0002640 331.8937 274.1784 01.00285599 16790

i pasted in my ISS TLE and got the result i had been looking for in my example string... that told me that /I/ had goofed something... turns out that i had dropped a '3' in the decimal julian day portion of the number... there should have been three 3s together... it made all the difference, too ;)

Sven Barth
to waldo kitty: TYPO ALERT! that should be .93338171... with the additional '3' in there, the final value…
waldo kitty wrote 43 lines
> Especially you can try JulianToDateTime and UnixToDateTime. Both return a > TDateTime which you can convert to a string using FormatDateTime > ( > http://www.freepascal.org/docs-html/rtl/sysutils/datetimetostring.html > ) or > DateTimeToStr ( > http://www.freepascal.org/docs-html/rtl/sysutils/datetimetostr.html ). i think i might be able to do something with the JulianToDateTime once i get the base year portion converted to a true julian... i spotted some C# code while doing a bit of research earlier (see below)... it appears to convert the year to a julian year and then add the decimal day portion... this should then be a proper julian date which i should be able to handle ;) [---- WARNING: C# code follows ----] double getJulianDay_Year(int year) { double dYear = year - 1; double A = Math.Floor(dYear / 100); double B = 2 - A + Math.Floor(A / 4); //The use of 30.600000000000001 is to correct for floating point rounding problems double dResult = Math.Floor(365.25 * dYear) + 1721422.9 + B; return dResult; } double getJulianDay_SatEpoch(int year, double dSatelliteEpoch) { //Tidy up the year and put it into the correct century year = year % 100; if (year < 57) year += 2000; else year += 1900; double dResult = getJulianDay_Year(year); dResult += dSatelliteEpoch; return dResult; } [---- end of C# code ----] looks like it should be easy to convert to pascal, too ;) just gotta find out what that "floor" routine does ;)

Well... I would say the same as FPC's "floor" routine ( http://www.freepascal.org/docs-html/rtl/math/floor.html ) does ;)

A hint for converting C# code: it might help to google for (in this case) "Math.Floor .net" which will often result in a MSDN link like this one: http://msdn.microsoft.com/en-us/library/e0b5f0xb.aspx

Regards,
Sven

Mark Morgan Lloyd
to waldo kitty: TYPO ALERT! that should be .93338171... with the additional '3' in there, the final value…
waldo kitty wrote 6 lines
i think i might be able to do something with the JulianToDateTime once i get the base year portion converted to a true julian... i spotted some C# code while doing a bit of research earlier (see below)... it appears to convert the year to a julian year and then add the decimal day portion... this should then be a proper julian date which i should be able to handle ;)

Don't know whether any of this will help

If this is any use...

FUNCTION CalcJD(year, month, day: INTEGER): DOUBLE;
//***********************************************************************/
//* Name:    CalcJD                                                     */
//* Type:    Function                                                   */
//* Purpose: Julian day from calendar day                               */
//* Arguments:                                                          */
//*   year : 4 digit year                                               */
//*   month: January = 1                                                */
//*   day  : 1 - 31                                                     */
//* Return value:                                                       */
//*   The Julian day corresponding to the date                          */
//* Note:                                                               */
//*   Number is returned for start of day.  Fractional days should be   */
//*   added later.                                                      */
//***********************************************************************/
VAR     A, B: INTEGER;
         JD: DOUBLE;
BEGIN
   IF month <= 2 THEN BEGIN
     year -= 1;
     month += 12
   END;
   A:= Floor(year / 100);
   B:= 2 - A + Floor(A / 4);
   JD:= Floor(365.25 * (year + 4716)) + Floor(30.6001 * (month + 1)) +
day + B - 1524.5;
   RESULT:= JD
END { CalcJD } ;

That was derived from some calculations published by NOAA, it's actually sunrise/sunset times and I transcribed it from Javascript a few months ago and which appeared to test OK.

Also

FUNCTION jTime(t: Int64): DOUBLE;
// jtime - convert internal date and time to astronomical Julian
// time (i.e. Julian date plus day fraction)
BEGIN
   RESULT:= t;
   RESULT:= (RESULT / 86400.0) + 2440587.5       // (seconds /(seconds
per day)) + julian date of epoch
END { jTime } ;
FUNCTION jDayToSecs(jday: DOUBLE): Int64;
// jdaytosecs - convert Julian date to a UNIX epoch
BEGIN
   RESULT:= Round((jday - 2440587.5) * 86400)   // (juliandate - jdate
of unix epoch)*(seconds per julian day)
END { jDayToSecs } ;
PROCEDURE jYear(td: DOUBLE; VAR yy, mm: Int64; VAR dd: DOUBLE);
// jyear - convert Julian date to year, month, day, which are
// returned via integer pointers to integers
VAR     z, a, alpha, b, c, d, e: Int64;
         f: DOUBLE;
BEGIN
   td:= td + 0.5;                       // astronomical to civil
   z:= Floor(td);
   f:= td - z;
   IF z < 2299161 THEN
     a:= z
   ELSE BEGIN
     alpha:= Floor((z - 1867216.25) / 36524.25);
     a:= z + 1 + alpha - Floor(alpha / 4)
   END;
   b:= a + 1524;
   c:= Floor((b - 122.1) / 365.25);
   d:= Floor(365.25 * c);
   e:= Floor((b - d) / 30.6001);
(* Note here: both MoonPhase.pm and moontool.c lose fractional days at
this     *)
(* point since dd is declared as an integer; Perl programmers might not
in      *)
(* fact notice this due to loose type handling. I think this is a bug
since it  *)
(* prevents using non-GMT time ranges. MarkMLl.
         *)
   dd:= b - d - Floor(30.6001 * e) + f;
   IF e < 14 THEN
     mm:= e - 1
   ELSE
     mm:= e - 13;
   IF mm > 2 THEN
     yy:= c - 4716
   ELSE
     mm:= c - 4715
END { jYear } ;
PROCEDURE jYear(td: DOUBLE; VAR yy, mm, dd: Int64);
// jyear - convert Julian date to year, month, day, which are
// returned via integer pointers to integers
(* This is equivalent to the original jYear() which loses fractional
days.      *)
(* MarkMLl.
         *)
VAR     y, m: Int64;
         d: DOUBLE;
BEGIN
   jYear(td, y, m, d);
   yy:= y;
   mm:= m;
   dd:= Trunc(d)
END { jYear } ;

which was transcribed from Perl (originally written in C) Moon phase calculations and again I believe tests OK.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
waldo kitty
to Sven Barth: Well... I would say the same as FPC's "floor" routine (…
Sven Barth wrote
On 16.01.2012 17:57, waldo kitty wrote:

[TRIM]

Show quoted text 5 lines
> looks like it should be easy to convert to pascal, too ;) just gotta > find out what that "floor" routine does ;) Well... I would say the same as FPC's "floor" routine ( http://www.freepascal.org/docs-html/rtl/math/floor.html ) does ;)

hehe, exactly... and it was easy to convert, too...

function getJulianDay_Year(year:integer) : double;
var
   dYear,
   a,b,
   dResult : double;
begin
   dYear := year - 1;
   A := Floor(dYear / 100);
   B := 2 - A + Math.Floor(A / 4);
   //The use of 30.600000000000001 is to correct for floating point rounding
problems
   dResult := Floor(365.25 * dYear) + 1721422.9 + B;
   getJulianDay_Year := dResult;
end;
function getJulianDay_SatEpoch(year:integer; dSatelliteEpoch:double) : double;
var
   dResult : double;
begin
   //Tidy up the year and put it into the correct century
   year := year mod 100;
   if (year < 57) then
     year := year + 2000
   else
     year := year + 1900;
   dResult := getJulianDay_Year(year);
   dResult := dResult + dSatelliteEpoch;
   getJulianDay_SatEpoch := dResult;
end;

with this TLE epoch number, 12013.93338171, ya feed it like so...

var
   JEpoch : double;
   DT : TDateTime;
[...]
JEpoch := getJulianDay_SatEpoch(12,013.93338171);
[...]
   if TryJulianDateToDateTime(JEpoch,DT) then
     writeln(FormatDateTime('YYYY MM DD hh:mm:ss',DT));

the above /should/ return 2012 01 14 22:24:04... i'm getting the right dates back but all of the times are 00:00:00 :(

do JulianDateToDateTime and TryJulianDateToDateTime not do anything with hours, minutes, seconds and milliseconds??

i'd give TryModifiedJulianDateToDateTime a try but the docs state that just trying to use that routine raises an exception... is it going to handle the hors, minutes, seconds, and milliseconds when it gets done or is it for some other julian date format??

[ aside: where/how does one report documentation errors? PadLeft says to see also PadLeft instead of PadRight ;) ]

waldo kitty
to Mark Morgan Lloyd: Don't know whether any of this will help If this is any use... FUNCTION CalcJD(year,…
Mark Morgan Lloyd wrote 9 lines
waldo kitty wrote: > i think i might be able to do something with the JulianToDateTime once i get > the base year portion converted to a true julian... i spotted some C# code > while doing a bit of research earlier (see below)... it appears to convert the > year to a julian year and then add the decimal day portion... this should then > be a proper julian date which i should be able to handle ;) Don't know whether any of this will help

that actually looks very similar to some of my old TP/BP 6/7 time libraries that i created because there was not much available out there when i needed it... the one part that hit me the most was that the fractional days stuff is lost and that's one part of what i'm looking for... however, i think i do have a method to pull it out... maybe i can make it generic enough for use elsewhere where decimal julian dates are used... i'm still coding it in my head and will be putting fingers to keyboard in just a bit to actually put it into operation ;)

thanks for the input!

Sven Barth
to waldo kitty: [TRIM] hehe, exactly... and it was easy to convert, too... function…
waldo kitty wrote 18 lines
with this TLE epoch number, 12013.93338171, ya feed it like so... var JEpoch : double; DT : TDateTime; [...] JEpoch := getJulianDay_SatEpoch(12,013.93338171); [...] if TryJulianDateToDateTime(JEpoch,DT) then writeln(FormatDateTime('YYYY MM DD hh:mm:ss',DT)); the above /should/ return 2012 01 14 22:24:04... i'm getting the right dates back but all of the times are 00:00:00 :( do JulianDateToDateTime and TryJulianDateToDateTime not do anything with hours, minutes, seconds and milliseconds??

A quick look at the code reveiled that it doesn't handle it. But at least that one should be the same as the one TDateTime uses, so you might try the following (which you can then pack into a function yourself):

var
   JEpoch: Double;
   DT: TDateTime;
begin
   JEpoch := getJulianDay_SatEpoch(12,013.9338171);
   if TryJulianDateToDateTime(JEpoch, DT) then begin
     DT := DT + Frac(JEpoch); // the time part should be the one after
the comma in both Julian and DateTime models
     Writeln(FormatDateTime('YYYY MM DD hh:nn:ss', DT)); // you need to
use "nn" for minutes as listed here:
http://www.freepascal.org/docs-html/rtl/sysutils/formatchars.html
   end;
end;
Show quoted text 5 lines
i'd give TryModifiedJulianDateToDateTime a try but the docs state that just trying to use that routine raises an exception... is it going to handle the hors, minutes, seconds, and milliseconds when it gets done or is it for some other julian date format??

The three "Modified Julian Date" functions are implemented as follows, so there should be no exception if you use the
TryModifiedJulianDateToDateTime function (this seems to be another documentation error then):

Function DateTimeToModifiedJulianDate(const AValue: TDateTime): Double;
begin
   result := DateTimeToJulianDate(AValue) - 2400000.5;
end;
Function ModifiedJulianDateToDateTime(const AValue: Double): TDateTime;
begin
   result := JulianDateToDateTime(AValue + 2400000.5);
end;
Function TryModifiedJulianDateToDateTime(const AValue: Double; out
ADateTime: TDateTime): Boolean;
begin
   Result:=TryJulianDateToDateTime(AValue + 2400000.5, ADateTime);
end;
[ aside: where/how does one report documentation errors? PadLeft says to see also PadLeft instead of PadRight ;) ]

You can report all documentation errors at http://bugs.freepascal.org as well. Just select as Category "Documentation".

Regards,
Sven

Mark Morgan Lloyd
to waldo kitty: that actually looks very similar to some of my old TP/BP 6/7 time libraries that i…
waldo kitty wrote 10 lines
> Don't know whether any of this will help that actually looks very similar to some of my old TP/BP 6/7 time libraries that i created because there was not much available out there when i needed it... the one part that hit me the most was that the fractional days stuff is lost and that's one part of what i'm looking for... however, i think i do have a method to pull it out... maybe i can make it generic enough for use elsewhere where decimal julian dates are used... i'm still coding it in my head and will be putting fingers to keyboard in just a bit to actually put it into operation ;)

The ultimate reference for almost all this stuff usually turns out to be one of Jean Meeus's books.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
waldo kitty
to Sven Barth: A quick look at the code reveiled that it doesn't handle it. But at least that one should…
Sven Barth wrote 21 lines
On 16.01.2012 20:06, waldo kitty wrote: > with this TLE epoch number, 12013.93338171, ya feed it like so... > > var > JEpoch : double; > DT : TDateTime; > > [...] > JEpoch := getJulianDay_SatEpoch(12,013.93338171); > [...] > if TryJulianDateToDateTime(JEpoch,DT) then > writeln(FormatDateTime('YYYY MM DD hh:mm:ss',DT)); > > > the above /should/ return 2012 01 14 22:24:04... i'm getting the right > dates back but all of the times are 00:00:00 :( > > do JulianDateToDateTime and TryJulianDateToDateTime not do anything with > hours, minutes, seconds and milliseconds?? A quick look at the code reveiled that it doesn't handle it.

i kinda figured that... however, here's a nice li'l :TripleFacePalm: for ya...

i tried to describe the format of the TLE Epoch number in an earlier post but i guess i pretty much failed... at least insofar as what the actual format is... here's what i posted previously...

[quote]

Show quoted text 10 lines
> 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

[/quote]

yes, that's the one where i dropped a '3' in the fractional part ;)

anyway, the format is like this...

*_TLE Epoch Format_*

eg: 12013.93338171

1. there are always 5 digits to the left of the decimal. the first two digits are the year of the epoch.

    if year<57 then year:=year+2000 else year:=year+1900
    in the above, 12 is the year which is 2012.

2. the next three digits (up to the decimal point) are the "day number of the year" of the TLE Epoch record.

in the above, 013 is the day number of the year. feed this plus the year to a julian date routine to find the julian date number. in this example, we're looking for the julian date number for the 13th day of 2012.

3. the digits from the decimal point to the end are the fractional part of the day. these are /not/ in julian date or julian day format.

in the above, .93338171 is the fractional part of the day. the time portion of the formula goes like this.

    fooo := frac(12013.93338171)
    rslt := fooo * 24    // 22.40116104
    hour := trunc(rslt)  // 22
    fooo := frac(rslt)   // .40116104
    rslt := fooo * 60    // 24.0696624
    mins := trunc(rslt)  // 24
    fooo := frac(rslt)   // .0696624
    rslt := fooo * 60    // 4.179744
    secs := trunc(rslt)  // 4
    fooo := frac(rslt)   // .179744
    rslt := fooo * 1000  // the more zeros, the more precision
    msec := trunc(rslt)  // 179

4. convert the julian date number from #2 to TDateTime. fill in the TDateTime time fields from #3. now EncodeDateTime and you'll have the proper numbers in a TDateTime record.

so what i ran into, besides the julian date routines not doing the time, but i was also sending the entire decimal number, without the year digits, to the julian date routine and that was just flat wrong since the fractional side wasn't a julian date fraction! ::TripleFacePalm::

so there's three pieces of data stored in that one "TLE Epoch" number and each has to be broken out and treated differently... now my answers finally agree with the programs i've been attempting to verify them against... i just couldn't see the forest for the trees and couldn't see the trees for all the leaves on'em :LOL:

Sven Barth
to waldo kitty
waldo kitty wrote 56 lines
anyway, the format is like this... *_TLE Epoch Format_* eg: 12013.93338171 1. there are always 5 digits to the left of the decimal. the first two digits are the year of the epoch. if year<57 then year:=year+2000 else year:=year+1900 in the above, 12 is the year which is 2012. 2. the next three digits (up to the decimal point) are the "day number of the year" of the TLE Epoch record. in the above, 013 is the day number of the year. feed this plus the year to a julian date routine to find the julian date number. in this example, we're looking for the julian date number for the 13th day of 2012. 3. the digits from the decimal point to the end are the fractional part of the day. these are /not/ in julian date or julian day format. in the above, .93338171 is the fractional part of the day. the time portion of the formula goes like this. fooo := frac(12013.93338171) rslt := fooo * 24 // 22.40116104 hour := trunc(rslt) // 22 fooo := frac(rslt) // .40116104 rslt := fooo * 60 // 24.0696624 mins := trunc(rslt) // 24 fooo := frac(rslt) // .0696624 rslt := fooo * 60 // 4.179744 secs := trunc(rslt) // 4 fooo := frac(rslt) // .179744 rslt := fooo * 1000 // the more zeros, the more precision msec := trunc(rslt) // 179 4. convert the julian date number from #2 to TDateTime. fill in the TDateTime time fields from #3. now EncodeDateTime and you'll have the proper numbers in a TDateTime record. so what i ran into, besides the julian date routines not doing the time, but i was also sending the entire decimal number, without the year digits, to the julian date routine and that was just flat wrong since the fractional side wasn't a julian date fraction! ::TripleFacePalm:: so there's three pieces of data stored in that one "TLE Epoch" number and each has to be broken out and treated differently... now my answers finally agree with the programs i've been attempting to verify them against... i just couldn't see the forest for the trees and couldn't see the trees for all the leaves on'em :LOL:

Have you tried just adding the fractional part (which you called "fooo" above) to the TDateTime value returned by TryJulianToDateTime and then feeding that to FormatDatTime? It should give you the same result... (at least I hope that ^^)

Regards,
Sven