struct tmx

K

kid joe

Hi all,

Carrying on with my reading about new features in C99, I came across the
struct tmx, which is like struct tm but contains a few more fields dealing
with leap seconds.

How exactly do leap seconds work, and is it worth the trouble of using a
struct tmx instead of a struct tm generally?

Cheers,
Joe
 
K

Keith Thompson

kid joe said:
Carrying on with my reading about new features in C99, I came across the
struct tmx, which is like struct tm but contains a few more fields dealing
with leap seconds.

How exactly do leap seconds work, and is it worth the trouble of using a
struct tmx instead of a struct tm generally?

There is no struct tmx in C99, so any code that uses it will be
non-portable.

There is a struct tmx as part of Clive Feather's proposal,
<http://www.davros.org/c/wg14n793.txt>. The proposal is dated
1997-09-23; apparently it was intended for C99, but it wasn't
accepted. (I'd love to see better time zone handling in standard C.)

The existing struct tm does allow for leap seconds, by making the
"normal range" of the tm_sec member of struct tm [0,60] rather than
[0,59], but it doesn't say much else about them. The time() function
is generally going to give you the current time as computed by the
underlying system.
 
K

kid joe

kid joe said:
Carrying on with my reading about new features in C99, I came across the
struct tmx, which is like struct tm but contains a few more fields dealing
with leap seconds.

How exactly do leap seconds work, and is it worth the trouble of using a
struct tmx instead of a struct tm generally?

There is no struct tmx in C99, so any code that uses it will be
non-portable.

There is a struct tmx as part of Clive Feather's proposal,
<http://www.davros.org/c/wg14n793.txt>. The proposal is dated
1997-09-23; apparently it was intended for C99, but it wasn't
accepted. (I'd love to see better time zone handling in standard C.)

The existing struct tm does allow for leap seconds, by making the
"normal range" of the tm_sec member of struct tm [0,60] rather than
[0,59], but it doesn't say much else about them. The time() function
is generally going to give you the current time as computed by the
underlying system.

Hi Keith,

I guess the list of new features Im looking at was based on a draft and
not the final standard then? Hmm.

What do you think are the main problems with time zones? The gmtime and
localtime seem to have it pretty well dealt with AFAICS. I dont really
know what the issue is with leap seconds but I dont think its something
youd need to worry about every day.

Cheers,
Joe
 
K

Keith Thompson

kid joe said:
kid joe said:
Carrying on with my reading about new features in C99, I came across the
struct tmx, which is like struct tm but contains a few more fields dealing
with leap seconds.

How exactly do leap seconds work, and is it worth the trouble of using a
struct tmx instead of a struct tm generally?

There is no struct tmx in C99, so any code that uses it will be
non-portable.

There is a struct tmx as part of Clive Feather's proposal,
<http://www.davros.org/c/wg14n793.txt>. The proposal is dated
1997-09-23; apparently it was intended for C99, but it wasn't
accepted. (I'd love to see better time zone handling in standard C.)

The existing struct tm does allow for leap seconds, by making the
"normal range" of the tm_sec member of struct tm [0,60] rather than
[0,59], but it doesn't say much else about them. The time() function
is generally going to give you the current time as computed by the
underlying system.

I guess the list of new features Im looking at was based on a draft and
not the final standard then? Hmm.

What do you think are the main problems with time zones? The gmtime and
localtime seem to have it pretty well dealt with AFAICS. I dont really
know what the issue is with leap seconds but I dont think its something
youd need to worry about every day.

For one thing, the mktime function takes a struct tm representing a
*local* time and converts it to a time_t. There's no corresponding
function that takes a struct tm representing a UTC time.

For another, the type struct tm itself contains no time zone
information. It doesn't even indicate whether it refers to a local
time, a UTC time, or a time in some other zone.
 
C

CBFalconer

kid said:
.... snip ...

I guess the list of new features Im looking at was based on a
draft and not the final standard then? Hmm.

The things marked C99 are the standard. n869 is the last draft
that was available in text format, and n869_txt.bz2 is a bzipped
package of it. n1256.pdf is the last C99 standard with all
updates.

Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://c-faq.com/> (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf> (C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2> (pre-C99)
<http://www.dinkumware.com/c99.aspx> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>
<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>
 
J

James Kuyper

kid said:
Hi all,

Carrying on with my reading about new features in C99, I came across the
struct tmx, which is like struct tm but contains a few more fields dealing
with leap seconds.

How exactly do leap seconds work, and is it worth the trouble of using a
struct tmx instead of a struct tm generally?

Wikipedia has a fairly good explanation of leap seconds. Of course, the
usual disclaimers apply when relying upon wikipedia. The most official
site I could find was <http://hpiers.obspm.fr/eop-pc/>.

For a great many purposes, leap seconds are completely ignorable.
However, if you need to calculate the time interval between two
different times with a sub-second accuracy, you need to determine
whether or not the instruments that determined those two times kept
track of leap seconds properly. If they did, leap seconds need to be
taken into consideration when determining how big that time interval is.

This is precisely the case for my own work; the MODIS instrument's
mirror sweeps its field of view across the surface of the Earth at 3000
km/s at nadir, and we're required to calculate what part of the earth's
surface the detectors are currently seeing reflected in that mirror with
an accuracy of +/-100m at 3 sigma. The clock that tracks the mirror
motion is automatically adjusted to reflect leap seconds; failing to
keep track of an entire leap second when we do our calculations would be
a disaster.
 
F

Franken Sense

In Dread Ink, the Grave Hand of Keith Thompson Did Inscribe:

The existing struct tm does allow for leap seconds, by making the
"normal range" of the tm_sec member of struct tm [0,60] rather than
[0,59], but it doesn't say much else about them. The time() function
is generally going to give you the current time as computed by the
underlying system.

The same is true in fortran, where we also have milliseconds, so it was
quite a shock to see the range on the seconds go to sixty. When someone
mentioned "leapseconds," then I understood.
 
F

Franken Sense

In Dread Ink, the Grave Hand of James Kuyper Did Inscribe:
This is precisely the case for my own work; the MODIS instrument's
mirror sweeps its field of view across the surface of the Earth at 3000
km/s at nadir, and we're required to calculate what part of the earth's
surface the detectors are currently seeing reflected in that mirror with
an accuracy of +/-100m at 3 sigma. The clock that tracks the mirror
motion is automatically adjusted to reflect leap seconds; failing to
keep track of an entire leap second when we do our calculations would be
a disaster.

Can you say a few more words about this? There's questions of precision,
but I can't quite see the geometry of it. Are you talking of stereographic
Riemannian projection?
 
J

James Kuyper

Franken said:
In Dread Ink, the Grave Hand of James Kuyper Did Inscribe:


Can you say a few more words about this? There's questions of precision,
but I can't quite see the geometry of it. ...

This is going way off-topic; I just wanted to give a concrete example
from my own personal experience of a situation where the sub-second
timing involving leap-seconds is important. In the course of doing so, I
made a mistake, one that nobody who's likely to be visiting this
newsgroup is likely to recognize (or care about): the mirror motion is
reported using relative times, rather than absolute times, and as a
result is not sensitive to leap-second issues.

What I should have referred to is the second most rapidly moving part of
the system, which is the satellite itself. It moves at 7500 m/s, so
missing a leap second would cause a systematic error in our ground
positions of roughly 7500m, or roughly 75 times our entire error budget.
That's still more than enough to make tracking leap-seconds important;
but it's not as impressive as the error that could have been caused if
it had been the case that the calculation of the mirror motion were
sensitive to leap-second issues.

To address your question about the geometry: our calculations work
essentially by tracing light rays backwards. We start with a line of
sight from the center of the detector toward the center of the lens, and
trace that line of sight backwards, reflecting it through the rotating
mirror, and then from there to the surface of the earth. In the course
of this calculation, we do about six different coordinate system
transformations, several of which involve coordinates systems what are
moving with respect to each other. Those transformations depend upon the
rotation of the mirror, the current attitude and position of the
satellite, and the current rotation of the Earth. For the level of
precision required, we need to take into consideration the facts that
the Earth rotates neither at a constant rate, nor around a fixed
rotation axis. We start by approximating the earth as an ellipsoid, and
then adjust that using a Digital Elevation Model of the earth with 30
arcsecond resolution.
... Are you talking of stereographic
Riemannian projection?

The stereographic projection projects from a point on the surface of a
sphere, through another point on the surface of the sphere, to a flat
plane tangent to the sphere at the point opposite to the projection
point. If you ignore the reflection through the mirror, there's a
similarity between our algorithm and the stereographic projection, but
also a lot of differences. We're using an ellipsoid, not a sphere. The
projection point is at an altitude of 705 km, not on the surface of
ellipsoid. The focal plane on which our detectors lie can, if you ignore
the mirror, be considered to be approximately parallel to the earth's
surface, and just a few centimeters higher than the projection point,
and therefore not likely to touch the surface of the earth at any point
(though it could if the pitch or roll angles were high enough, but that
only happens during maneuvers). Also, we don't treat the coordinates on
the focal plane as components of a complex number, so "Riemannian"
doesn't apply, either.
 
K

Keith Thompson

good grief

I think the point of that web page is that different juridictions have
adopted UTC (Universal Coordinated Time) at different times, many of
them after some number of leap seconds had been added. Everyone
pretty much agrees on when new leap seconds are added, and on what
time it is now; the disagreement is on what time it was, say, 600
million seconds ago, with different jurisdictions recognizing
different numbers of leap seconds between then and now.
 
F

Franken Sense

In Dread Ink, the Grave Hand of James Kuyper Did Inscribe:
This is going way off-topic; I just wanted to give a concrete example
from my own personal experience of a situation where the sub-second
timing involving leap-seconds is important. In the course of doing so, I
made a mistake, one that nobody who's likely to be visiting this
newsgroup is likely to recognize (or care about): the mirror motion is
reported using relative times, rather than absolute times, and as a
result is not sensitive to leap-second issues.

What I should have referred to is the second most rapidly moving part of
the system, which is the satellite itself. It moves at 7500 m/s, so
missing a leap second would cause a systematic error in our ground
positions of roughly 7500m, or roughly 75 times our entire error budget.
That's still more than enough to make tracking leap-seconds important;
but it's not as impressive as the error that could have been caused if
it had been the case that the calculation of the mirror motion were
sensitive to leap-second issues.

To address your question about the geometry: our calculations work
essentially by tracing light rays backwards. We start with a line of
sight from the center of the detector toward the center of the lens, and
trace that line of sight backwards, reflecting it through the rotating
mirror, and then from there to the surface of the earth. In the course
of this calculation, we do about six different coordinate system
transformations, several of which involve coordinates systems what are
moving with respect to each other. Those transformations depend upon the
rotation of the mirror, the current attitude and position of the
satellite, and the current rotation of the Earth. For the level of
precision required, we need to take into consideration the facts that
the Earth rotates neither at a constant rate, nor around a fixed
rotation axis. We start by approximating the earth as an ellipsoid, and
then adjust that using a Digital Elevation Model of the earth with 30
arcsecond resolution.

How would you describe the curvature of the mirror?
The stereographic projection projects from a point on the surface of a
sphere, through another point on the surface of the sphere, to a flat
plane tangent to the sphere at the point opposite to the projection
point. If you ignore the reflection through the mirror, there's a
similarity between our algorithm and the stereographic projection, but
also a lot of differences. We're using an ellipsoid, not a sphere. The
projection point is at an altitude of 705 km, not on the surface of
ellipsoid. The focal plane on which our detectors lie can, if you ignore
the mirror, be considered to be approximately parallel to the earth's
surface, and just a few centimeters higher than the projection point,
and therefore not likely to touch the surface of the earth at any point
(though it could if the pitch or roll angles were high enough, but that
only happens during maneuvers). Also, we don't treat the coordinates on
the focal plane as components of a complex number, so "Riemannian"
doesn't apply, either.

I think the "Riemannian" part of it speaks to the corpus of work by the
mathematician of that name. Your satellite is 705 km high?
--
Frank

I said that Sean Hannity took residence up Newt Gingrich's butt from 94 to
98. I got that from British intelligence. It turns out he only took up
residence in 95.
~~ Al Franken
 
G

Guest

I think the point of that web page is that different juridictions have
adopted UTC (Universal Coordinated Time) at different times, many of
them after some number of leap seconds had been added.  Everyone
pretty much agrees on when new leap seconds are added, and on what
time it is now; the disagreement is on what time it was, say, 600
million seconds ago, with different jurisdictions recognizing
different numbers of leap seconds between then and now.

I understood that. It just scared the life out of me!
600Ms isn't all that long ago (32Ms ~ 1yr)
 
J

James Kuyper

Franken said:
In Dread Ink, the Grave Hand of James Kuyper Did Inscribe:
.... ....
How would you describe the curvature of the mirror?

It's flat; all focusing is done by the lenses; the purpose of the
rotating mirror is only to cause the field of view of the detectors to
scan across the surface of the earth.

Unfortunately, I've made yet another error:
... can, if you ignore

Actually, the entire purpose of the mirror is to have the same effect as
if the focal plane were moving in a circle around the the projection
point, always facing the projection point.
... just a few centimeters higher than the projection point,

As a result, the following statement is also incorrect:
....
... Also, we don't treat the coordinates on

I think the "Riemannian" part of it speaks to the corpus of work by the
mathematician of that name. ...

It does; but in this context, it refers specifically to that part of his
corpus of work which involves a mapping between the complex plan and the
surface of a sphere. We have a pair of numbers (the coordinates of
detectors on the focal plane), which we could treat as the components of
a complex number, just as Riemann did for that projection. We map those
points onto the surface of the earth, which can be approximated as a
sphere, though we do not make that approximation. However, we don't
treat those coordinates as complex numbers, so the analogy breaks down.
... Your satellite is 705 km high?

Yes.
 
F

Franken Sense

In Dread Ink, the Grave Hand of James Kuyper Did Inscribe:
It's flat; all focusing is done by the lenses; the purpose of the
rotating mirror is only to cause the field of view of the detectors to
scan across the surface of the earth.

It's flat but can move in a plane orthogonal to the ray that connects the
center of the earth and the satellite. How would you describe the motion
of the mirror?

And the 98.6 degrees is the difference between the plane of motion and the
plane containing the equator?
 
J

James Kuyper

Franken said:
In Dread Ink, the Grave Hand of James Kuyper Did Inscribe:


It's flat but can move in a plane orthogonal to the ray that connects the
center of the earth and the satellite. ...

Both the focal plane and the mirror are flat. The mirror is what it
actually rotating. In order to make a comparison with the Riemannian
stereographic projection that you were asking about, I removed the
mirror from the description, by describing the situation in terms of
causing the focal plane to rotate around what is actually the mirror's
rotation axis.
... How would you describe the motion
of the mirror?

It is flat elliptical mirror, rotating around it's short axis, which is
normally oriented in the same direction as the motion of the spacecraft
in it's orbit around the earth. To save space, the path that light
travels through the instrument is folded by several fixed mirrors, but
the result of those fixed mirrors is to cause the effective location of
the focal plane (and the corresponding focal point) to be offset from
the mirror in a mainly horizontal direction perpendicular to the
mirror's rotation axis.

And the 98.6 degrees is the difference between the plane of motion and the
plane containing the equator?

Sort of - but that description would raise the question of why we say
the angle is 98.6 degrees rather than 81.4 degrees. The reason is that
the satellite is rotating in the opposite direction from the Earth's
rotation; if it were rotating in the same direction, it would have been
listed as 81.4 degrees.
 
F

Franken Sense

In Dread Ink, the Grave Hand of James Kuyper Did Inscribe:
Both the focal plane and the mirror are flat. The mirror is what it
actually rotating. In order to make a comparison with the Riemannian
stereographic projection that you were asking about, I removed the
mirror from the description, by describing the situation in terms of
causing the focal plane to rotate around what is actually the mirror's
rotation axis.

And there is no "glomping" on the edges. The mirror is flat?
It is flat elliptical mirror, rotating around it's short axis, which is
normally oriented in the same direction as the motion of the spacecraft
in it's orbit around the earth. To save space, the path that light
travels through the instrument is folded by several fixed mirrors, but
the result of those fixed mirrors is to cause the effective location of
the focal plane (and the corresponding focal point) to be offset from
the mirror in a mainly horizontal direction perpendicular to the
mirror's rotation axis.



Sort of - but that description would raise the question of why we say
the angle is 98.6 degrees rather than 81.4 degrees. The reason is that
the satellite is rotating in the opposite direction from the Earth's
rotation; if it were rotating in the same direction, it would have been
listed as 81.4 degrees.

I think a person assumes celestial north and a right-hand rule. Let's
assume we look at the satellite as it comes over the north pole bearing
south. (Speed also 3000 km/s? at zenith)

It zooms south on the atlantic. Let us consider two cities in the us that
are the same latitude, say Chicago and Portland. As the satellite passes
New York, is the angle formed by (Portland, Chicago, sattelite) between 97
and 99?
 
J

James Kuyper

Franken said:
In Dread Ink, the Grave Hand of James Kuyper Did Inscribe:
....

And there is no "glomping" on the edges. The mirror is flat?

Yes. I'm not sure what you're thinking about with respect to "glomping".

....
I think a person assumes celestial north and a right-hand rule. Let's
assume we look at the satellite as it comes over the north pole bearing
south. (Speed also 3000 km/s? at zenith)

The satellite never comes closer to the the north pole than latitude 81.4N.

3000 km/s would be well in excess of escape velocity. The orbital speed
is a fairly constant 7500 m/s in Earth Centered Inertial coordinates.
Relative to the surface of the Earth, you have to adjust for the
rotation rate of the earth. However, that's never a large adjustment
compared to 7500 m/s.

I should have given you this link a long time ago, but I didn't expect
you to have so much interest in the subject:
It zooms south on the atlantic. Let us consider two cities in the us that
are the same latitude, say Chicago and Portland. As the satellite passes
New York, is the angle formed by (Portland, Chicago, sattelite) between 97
and 99?

Since you've specified that the satellite is passing over New York, the
answer to that question depends only upon the positions of the three
cities and the altitude of the satellite; it has nothing to do with the
orbital inclination.

There's a MODIS instrument on two different satellites, Terra and Aqua.
I hope that these will help you visualize the orbits of those satellites
better: <http://www.ssec.wisc.edu/datacenter/terra/>
<http://www.ssec.wisc.edu/datacenter/aqua/>

We've long since passed the point where putting "OT" in the subject line
justifies allowing this sub-thread to continue. If you have any further
questions along these lines, please direct them to me by e-mail in my
official capacity, at (e-mail address removed).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,756
Messages
2,569,540
Members
45,024
Latest member
ARDU_PROgrammER

Latest Threads

Top