Network time to C time

[Andrew Chalk]

Network time uses 1900 as its base. The C time library uses 1970. I want to
convert a network time value to a C library time. I.e. I have to subtract
the number of seconds from 1900 to 1970. Is there any library function to do
this?

Thanks.

 

[CBFalconer]

Network time uses 1900 as its base. The C time library uses 1970.
I want to convert a network time value to a C library time. I.e.
I have to subtract the number of seconds from 1900 to 1970. Is
there any library function to do this?

For heavens sake, why? That number is a constant. Just subtract
it. And all this is off-topic anyhow.

 

[Richard]

For heavens sake, why? That number is a constant. Just subtract
it. And all this is off-topic anyhow.

How the hell is asking about the existence for a C library function to
manipulate dates and times "Off Topic"?!?!?!?! Streuth.

 

[Kenny McCormack]

CBFalconer said:


Hardly a constant. Not all C libraries use 1970 as their base, so the
number of seconds between the network epoch and a C library epoch is in
fact not constant at all.

True. Because "networks" are not mentioned in the C standards documents.
And, I think, neither are "epochs".

Why?

Because "networks" are not mentioned in the C standards documents.

 

[Walter Roberson]

Andrew Chalk wrote:

For heavens sake, why? That number is a constant. Just subtract
it.

Having it as a library function would save questions about (e.g.,)
whether either (or both) libraries take leap-seconds into account.

Also, the number of seconds between 1900 and 1970 is not representable
in a signed long (just misses -- signed long gets you a little over
68 years). That implies that if network time is defined as an
unsigned long that it runs out before C time runs out; if it is defined
some other way then a straight-forward subtraction is not appropriate
in C89. (Possibly network time is defined as long long, but if so then
it wouldn't be representable in C89, which seems unlikely.)

 

[Richard Heathfield]

CBFalconer said:

For heavens sake, why? That number is a constant. Just subtract
it.

Hardly a constant. Not all C libraries use 1970 as their base, so the
number of seconds between the network epoch and a C library epoch is in
fact not constant at all.

And all this is off-topic anyhow.

Why?

 

[Keith Thompson]

Network time uses 1900 as its base. The C time library uses 1970. I
want to convert a network time value to a C library time. I.e. I
have to subtract the number of seconds from 1900 to 1970. Is there
any library function to do this?

No, there's no standard library function to do this. There may well
be a non-standard function; a newsgroup that deals with your operating
system is likely to be more helpful.

Incidentally, standard C doesn't require time_t to represent seconds
since 1970, though that's the most common implementation.

 

[Keith Thompson]

For heavens sake, why? That number is a constant. Just subtract
it. And all this is off-topic anyhow.

No, the question isn't off-topic (in comp.lang.c); the answer just
happens to be no.

 

[Andrew Chalk]

And that constant is, what?

For heavens sake, why? That number is a constant. Just subtract
it. And all this is off-topic anyhow.

 

[Thad Smith]

Network time uses 1900 as its base. The C time library uses 1970. I want to
convert a network time value to a C library time. I.e. I have to subtract
the number of seconds from 1900 to 1970. Is there any library function to do
this?

You have received earlier comments that
1. the number of seconds is a constant so you can simply subtract it
2. the number of seconds is not constants, since different C
implementations use different starting points
3. you may need to consider leap seconds and might not be able to
represent the time in a single C89 variable

These are all valid comments, in general. The simple problem
description leaves details open to interpretation.

For a given pair of defined time scales, i.e., a particular network time
specification and a particular C library implementation which uses a
representation of number of elapsed seconds since a starting point,
there is likely a single value to can be used to convert one time scale
to another.

If you a writing a portable implementation for all Standard C
implementations, but a single network standard, you can convert the
network time to a struct tm representation of local time, then use
mktime() to obtain the time_t representation.

If it is important to accurately handle leap seconds, you need to
consult the specification for your network time representation and
verify that your target C libraries have adequate handling. For most
uses it doesn't matter.

 

[Keith Thompson]

And that constant is, what?

Please don't top-post. Read the following:

http://www.caliburn.nl/topposting.html
http://www.cpax.org.uk/prg/writings/topposting.php

Please don't quote signatures (the stuff following the "-- " line)
unless you're actually commenting on them. More generally, when you
post a followup, retain just enough of the parent article so your
reply makes sense on its own.

I've corrected both here.

The number of seconds between midnight 1900-01-01 and midnight
1970-01-01 is 2208988800. (That ignores leap seconds, but many time
representations also ignore leap seconds, which weren't introduced
until 1972 anyway.)

Knowing that might or might not be helpful. Though the C standard
says remarkably little about how times are represented, many systems
use a 32-bit signed integer representing seconds since 1970-01-01;
some systems do the same thing, but with a 64-bit signed intger.
(Using 1970-01-01 is a Unix standard, not a C standard, but it's
spread to some other operating systems for compatibility reasons.)

The value 2208988800 is (barely) too large to be represented in a
32-bit signed integer. There are probably ways around that, but
they'll depend on exactly how your "network time" is represented.
Adding 1104494400 twice *might* be a solution.

It's very likely that there's already a function that will reliably
convert between "network time" and "Unix time". You should ask in
comp.unix.programmer rather than soliciting guesses in comp.lang.c.

 

[Barry Schwarz]

Network time uses 1900 as its base. The C time library uses 1970. I want to
convert a network time value to a C library time. I.e. I have to subtract
the number of seconds from 1900 to 1970. Is there any library function to do
this?

While Unix may use 1970 as time 0, the standard does not require any
of the library functions to do so.

Furthermore, the representation of time is not required to be in
seconds. (For example, Excel uses a floating point value of days and
fractions thereof.)

You can compute the value you need using the difftime function.


Remove del for email

 

[Kenny McCormack]

While Unix may use 1970 as time 0, the standard does not require any
of the library functions to do so.

Furthermore, the representation of time is not required to be in
seconds. (For example, Excel uses a floating point value of days and
fractions thereof.)

I doubt Excel is mentioned in the C standards documents.

Therefore, it is OT here.

 

[Keith Thompson]

While Unix may use 1970 as time 0, the standard does not require any
of the library functions to do so.

Furthermore, the representation of time is not required to be in
seconds. (For example, Excel uses a floating point value of days and
fractions thereof.)

True, though Excel's time representation presumably isn't time_t.
Probably Excel runs on a system where time_t represents seconds since
1970 (in the C implementation if not in the operating system), and it
defines its own internal type for representing dates and times. But
yes, a C implementation *could* define time_t as a floating-point type
representing days and fractions thereof.

You can compute the value you need using the difftime function.

Um, maybe. difftime() computes the difference between two time_t
values, yielding a double result. But there's no guarantee that
1900-01-01 00:00:00 can be represented as a time_t (and on many
systems it can't). For that matter, there's no guarantee that
1970-01-01 00:00:00 is within the range of time_t (though I suspect it
is under all existing implementations).

But the computation isn't difficult. It's 70 years of 365 days each,
each day being 86400 seconds (24 * 60 * 60), plus 17 leap days of
86400 seconds each (1900 was not a leap year).

I'm assuming that this "network time" uses 1900-01-01 as its epoch.
The OP just said 1900, and I've think I've heard of representations
that use 1900-03-01 or 1901-01-01 to avoid the leap year irregularity.
If the OP is referring to NTP, then yes, the epoch is 1900-01-01 (and
the representation, which uses 32 bits for the whole number of seconds
and 32-bits for the fraction, will wrap around in 2036).

 

[Joe Wright]

True, though Excel's time representation presumably isn't time_t.
Probably Excel runs on a system where time_t represents seconds since
1970 (in the C implementation if not in the operating system), and it
defines its own internal type for representing dates and times. But
yes, a C implementation *could* define time_t as a floating-point type
representing days and fractions thereof.


Um, maybe. difftime() computes the difference between two time_t
values, yielding a double result. But there's no guarantee that
1900-01-01 00:00:00 can be represented as a time_t (and on many
systems it can't). For that matter, there's no guarantee that
1970-01-01 00:00:00 is within the range of time_t (though I suspect it
is under all existing implementations).

But the computation isn't difficult. It's 70 years of 365 days each,
each day being 86400 seconds (24 * 60 * 60), plus 17 leap days of
86400 seconds each (1900 was not a leap year).

I'm assuming that this "network time" uses 1900-01-01 as its epoch.
The OP just said 1900, and I've think I've heard of representations
that use 1900-03-01 or 1901-01-01 to avoid the leap year irregularity.
If the OP is referring to NTP, then yes, the epoch is 1900-01-01 (and
the representation, which uses 32 bits for the whole number of seconds
and 32-bits for the fraction, will wrap around in 2036).

The idea that seconds since 1970 will wrap in 2036 assumes an integer
and 31 bits, not 32. With 32 bits we can live into 2109.

 

[Richard Bos]

The idea that seconds since 1970 will wrap in 2036 assumes an integer
and 31 bits, not 32. With 32 bits we can live into 2109.

No, it's NTP, with 32 bits unsigned, and hence 136.summat years, since
1900, which will overflow in 2036. As noted, BTW, in the relevant RFC.

Richard

 

[Keith Thompson]

Keith Thompson wrote: [...]

If the OP is referring to NTP, then yes, the epoch is 1900-01-01 (and
the representation, which uses 32 bits for the whole number of seconds
and 32-bits for the fraction, will wrap around in 2036).

The idea that seconds since 1970 will wrap in 2036 assumes an integer
and 31 bits, not 32. With 32 bits we can live into 2109.

NTP uses a 32-bit unsigned integer to represent seconds since 1900
(plus another 32 bits to represent fractional seconds); this wraps
around in 2036. Many Unix-like systems use a 32-bit signed integer to
represent seconds since 1970; this overflows in 2038.

For Unix-like systems, switching from 32-bit signed to 32-bit unsigned
would delay the overflow to 2106 (not 2109). However, both NTP and
Unix are migrating to 64 bits, so there's no need to use unsigned
integers and thereby lose the ability to represent dates before the
epoch.

These are, of course, just examples of possible representations for
time_t.

 

[Chip Coldwell]

For heavens sake, why? That number is a constant. Just subtract
it. And all this is off-topic anyhow.

Is it? Does it include, for example, leap seconds?

Chip

 

[Kenny McCormack]

Is it?

It is OT because there is no mention of networks in the C standards
documents. In the dogma of this ng, the instant you mention something
not mentioned in the C standards documents, you lose.

Does it include, for example, leap seconds?

Others have pointed out that there were no leap seconds prior to 1970.

 

[Richard]

It is OT because there is no mention of networks in the C standards
documents. In the dogma of this ng, the instant you mention something
not mentioned in the C standards documents, you lose.


Others have pointed out that there were no leap seconds prior to 1970.

Are leap seconds mentioned in the C-Standard? ...