Prev: overloading for multiple arithmetic operations
Next: Perfect forwarding of default constructor?
From: nmm1 on 16 Jul 2010 17:03
In article <i1q8eh$u3b$1(a)usenet.stanford.edu>,
Seungbeom Kim <musiphil(a)bawi.org> wrote:
>
>> Using setenv("TZ",... is a thoroughly bad idea, though,
>
>Can you explain why? I have used the trick (in perl, not in C or C++,
>though, but the basic idea is the same), and it has worked well in
>the web program that shows the date and time in each user's timezone
>as specified in his/her settings.

Because there is no guarantee that the run-time system will look
for the variable every time it uses it! The most obvious efficient
implementation is that it looks at it only at program start. Also
setting it may not apply to the current process, but only to new
ones spawned from it. Even assuming that it is available - it's
not part of standard C++, after all!

>> and using locales is better (but still problematic).
>
>You mean locales such as en_US.utf8 or ko_KR.eucKR?
>How are they involved in timezones?

No. I mean as in setlocale, as specified in the C standard. If you
read the standards more carefully, you will find that the environment
viable "TZ" does not affect the time functions directly, but does
so by affecting the locale, which then affects the time functions.

>> Not all C++ implementations will allow you to set the environment,
>> or use the value you have set if you do.
>
>That's why I said 'not in "standard" C++, but the GNU C Library...',
>of course. But isn't it specified in POSIX? (I see that setenv conforms
>to POSIX, but I don't know exactly what POSIX says about setenv.)

And that's why I said "not all C++ implementations". Ones that use
the GNU C library are only a small subset. Also, POSIX is ambiguous
about what happens if you change environment variables like "TZ".
and, in any case, not all C++ implementations run under POSIX;
in some cases, the system doesn't even HAVE environment variables!

>>>> and do some simple arithmetic
>>>> (e.g. "add" 1 day to or "subtract" 1 day from it),
>>>
>>> I'm not sure if the "standard" C or C++ provides any defined way for
>>> such a thing: it only provides difftime(time_t, time_t), and it makes
>>> me wonder, "Then why not addition?"
>>
>> Yes, it does. Convert it to broken-down time (in GMT), manipulate
>> that, and convert it back again. Ugh.
>
>Sorry, but I'm not sure if that's meant as a joke.
>Even if I start with a broken-down time, I will convert it to time_t
>and manipulate that. Manipulating broken-down times is reinventing
>the wheel, and not a trivial task.

It's not a joke. I answered your implied question - it is the defined
way that standard C and C++ provide to perform arithmetic on times.
The "ugh" may have alerted you to the fact that I don't regard it
as trivial, either.

>>> Anyway, if you're under POSIX, it is amazingly simple: time_t is an
>>> arithmetic type representing the number of seconds elapsed since the Epoch
>>> (1970-01-01T00:00:00Z, i.e. the midnight starting 1 January 1970 in UTC),
>>> and you just add or subtract seconds. One day is 86400 seconds.
>>
>> Provided that you don't need to handle time precisely - POSIX times
>> are unreliable in the region around leap seconds or over durations
>> spanning leap seconds, to within an error limited by the number of
>> leap seconds involved. And I mean "unreliable", too.
>
>Correct. But they are good enough for many purposes, and prevalent in
>Unix or Linux systems (they are often called 'Unix times'). If you need
>better precision, POSIX provides timeval or timespec, with millionths
>or billionths of seconds. They still ignore leap seconds, but neverthe-
>less they are used as system times (returned by gettimeofday) or file
>timestamps (ctime, mtime, atime).

Er, no. Those have EXACTLY the same problems. While I could describe
them in great detail, I doubt that most people are interested. There
is no handle sub-second times in POSIX reliably, unfortunately, because
the specification is such a thoroughgoing mess.


Regards,
Nick Maclaren.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: nmm1 on 18 Jul 2010 05:28
In article <i1tehf$oh2$1(a)usenet.stanford.edu>,
Seungbeom Kim <musiphil(a)bawi.org> wrote:
>>
>> Er, no. Those have EXACTLY the same problems. While I could describe
>> them in great detail, I doubt that most people are interested. There
>> is no handle sub-second times in POSIX reliably, unfortunately, because
>> the specification is such a thoroughgoing mess.
>
> What are those problems?
> (I hope they won't be rejected as off-topic... :))
>
> [if they don't involve C++, they are off-topic for this group --mod]

Not directly, though they affect it, so I will summarise briefly and
leave it to the moderator to decide whether to block my posting.

The problem is that timestamps and delays are measured in (true)
seconds, but that they are ALSO specified to correspond to UTC
as if there had been no leap seconds. Those are mathematically
incompatible. With the Advanced Realtime option, a programmer can
choose a type of clock (monotonic or whatever), but the properties
of those are not well-defined and timestamps and delays are not
flagged with their originating clock, anyway!

This means that anyone writing a program that depends on accuracy
to a second or better AND where it might cross a leap-second slot
is onto a complete loser. The implementation is faced with an
impossible task and, as a result, cannot deliver a reliable effect.
Astronomers and others who need to do that kick that whole mess
out of the window and use TAI, which was invented by those same
experts for that very purpose. Converting past TAI times to UTC
is trivial, and predicting the future is always guesswork :-)

Try a Web search for 'Markus Kuhn time' for more detail, by a
colleague of mine who tried to get this one sorted out.


Regards,
Nick Maclaren.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: nmm1 on 18 Jul 2010 05:30
In article <i1tehf$oh2$1(a)usenet.stanford.edu>,
Seungbeom Kim <musiphil(a)bawi.org> wrote:
>
>>>> and using locales is better (but still problematic).
>>>
>>> You mean locales such as en_US.utf8 or ko_KR.eucKR?
>>> How are they involved in timezones?
>>
>> No. I mean as in setlocale, as specified in the C standard. If you
>> read the standards more carefully, you will find that the environment
>> viable "TZ" does not affect the time functions directly, but does
>> so by affecting the locale, which then affects the time functions.
>
> Which standard and which clause? The C standard does not even mention
> the environment variable "TZ".
>
> And I don't see anything in the LC_* family or struct lconv that deals
> with timezones.

You're right there. I had forgotten that one had been omitted; it
was raised as an issue during either C90 or C99, but never got
addressed. Dynamic (and even user-controllable) timezones are not
supported by C, and hence not by C++. You are correct that it is
supported by POSIX.


Regards,
Nick Maclaren.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2
Prev: overloading for multiple arithmetic operations
Next: Perfect forwarding of default constructor?