Prev: gcc & glibc
Next: Proxy site open your favoraite sites facebook myspace ...etc
From: Ersek, Laszlo on 6 Jul 2010 10:36
(c.u.p. added)

On Tue, 6 Jul 2010, Eric Sosman wrote:

> On 7/6/2010 8:00 AM, Vincenzo Mercuri wrote:
>> Richard Heathfield ha scritto:
>>> Alexander Klauer wrote:
>>>> Vincenzo Mercuri wrote:
>>
>>>>> const time_t calendar_time = (time_t) 1278360000;
>>
>> Would it be legal on a Posix compliant environment (given that
>> 1278360000 is in Unix time) ?
>>
>> Or it is just not allowed to make assumptions on type time_t in general?
>
> POSIX systems place more requirements on time_t and its
> representation than C itself does. If you're writing for POSIX
> systems, you can rely on POSIX' extra guarantees (and extra
> capabilities). See comp.unix.programmer for more information.
>
> (In the specific matter of timekeeping, it's my understanding
> that POSIX *requires* a degree of inaccuracy by *defining* the day
> as 86400 seconds, leap seconds be damned. POSIX time is therefore
> twenty-four seconds off of UTC, and drifting slowly. But perhaps
> I've not understood the issues properly; again, comp.unix.programmer
> is a better place to ask. The C Standard does not require this
> inaccuracy -- but then, the C Standard does not require any stated
> degree of accuracy, either.)

I think you are right.

"Seconds Since the Epoch", normative:

http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15

Informative (rationale):

http://www.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_15

My interpretation:

IIUC, POSIX introduces its own "seconds since the Epoch" (= scalar) and
"UTC name" (= broken-down) definitions, and the strict correspondence
between them.

If one takes the current time (looking at his wristwatch) and considers it
a "UTC name", then the corresponding POSIX "seconds since the Epoch" value
is only an approximation of the number of seconds that have in fact
elapsed since the Epoch, in the real world. (This is the mktime()
direction.)

Conversely, the gettimeofday() -> localtime() chain should work
intuitively; the system ensures that gettimeofday() fills in such a value
that (1) has unspecified relation to the real-world number of seconds
elapsed since the Epoch, (2) makes localtime() return with a broken-down
"UTC name" that matches the wall-clock date and time of the gettimeofday()
call, and (3) is suitable for checking differences (under newer versions,
clock_gettime() with CLOCK_MONOTONIC should be used for that end).

The "wall-clock" and the "wristwatch" in the above is reset when Daylight
Saving Time requires it, and, more surprisingly, can display 61 seconds
(and 62, up to and including SUSv2).

(End of my interp.)

Returning to the original question, the cited SUSv4 Rationale says:

----v----
[...] it is important that all conforming systems interpret "536457599
seconds since the Epoch" as 59 seconds, 59 minutes, 23 hours 31 December
1986 [...]
----^----

The "seconds since the Epoch" expression is quoted in the above, thus it
should refer to the POSIX definition (ie. time_t), not the real-world
positive number.

lacos
 | 
Pages: 1
Prev: gcc & glibc
Next: Proxy site open your favoraite sites facebook myspace ...etc