UTC時間のstruct tmからtime_t への変換法
matsunaga
time_t形式の時間に変換する事は、
mktimeで可能ですが、
UTC時間の場合、何か良い方法はありますでしょうか？
宜しくお願い致します。
Atushi Sakauchi
At Mon, 14 May 2001 11:49:01 +0900,
matsunaga wrote:
>
> ローカル時間のstruct tm形式の時間から、
> time_t形式の時間に変換する事は、
> mktimeで可能ですが、
> UTC時間の場合、何か良い方法はありますでしょうか？
(処理系によっては) timegm() というライブラリ関数があります．
Hisao Aoyama
UNIX (XPG4?) なら
#include <time.h>
...
struct tm *utc_tm;
time_t desired_result;
tzset();
desired_result = mktime(utc_tm) + timezone;
といった感じでしょうか?
----
Hisao Aoyama 青山 尚夫
ASTEC Products, Inc. （株）アステック・プロダクツ
aoy...@astec.co.jp
Kazuo Fox Dohzono
"matsunaga" <matu...@rd.casio.co.jp> writes:
> ローカル時間のstruct tm形式の時間から、
> time_t形式の時間に変換する事は、
> mktimeで可能ですが、
> UTC時間の場合、何か良い方法はありますでしょうか？
# C99 では解決されるという情報もあったんだけど….
先輩のメイルから.
| #include <time.h>
|
| time_t mktime_UTC(struct tm *t)
| {
| struct tm epoch;
| time_t timet;
|
| timet = (time_t)0;
| epoch = *gmtime(&timet);
| epoch.tm_mday++;
| t->tm_mday++;
| if (t->tm_isdst < 0)
| t->tm_isdst = 0;
| timet = mktime(t) - mktime(&epoch);
| *t = *gmtime(&timet);
| return timet;
| }
| Jan 1 ではなく 1 日ずらしたのは, Jan 1 だと mktime() でエラーとな
| る可能性が否定できないからです。例えば JST の Jan 1 00:00 1970 は,
| UTC ではまだ Dec 31 15:00 1969 ですから, time_t の値が負になってしま
| います。
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp
[12],(6,9),0,0,2
(4/1449/3742)
Kazuo Fox Dohzono
Hisao Aoyama <aoy...@astec.co.jp> writes:
> #include <time.h>
> ...
> struct tm *utc_tm;
> time_t desired_result;
>
> tzset();
> desired_result = mktime(utc_tm) + timezone;
>
> といった感じでしょうか?
夏時間を考慮する必要がありますね.
Hisao Aoyama
> In article <v4zocgs...@astec.co.jp>
> Hisao Aoyama <aoy...@astec.co.jp> writes:
>
> > #include <time.h>
> > ...
> > struct tm *utc_tm;
> > time_t desired_result;
> >
> > tzset();
> > desired_result = mktime(utc_tm) + timezone;
> >
> > といった感じでしょうか?
>
> 夏時間を考慮する必要がありますね.
そうすると...
desired_result = mktime(utc_tm) + daylight ? altzone : timezone;
Hisao Aoyama
> > > tzset();
> desired_result = mktime(utc_tm) + daylight ? altzone : timezone;
tzset() と mktime() の間に，day light saving が
終わったら/始まったらどうする，とい話はありますね．
一方，
In article <9do047$27lm$1...@news2.rim.or.jp>
doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
> | t->tm_mday++;
tm_mday が 32 になってしまったら，というのは気に
しなくて良いのでしょうか?
Kazuo Fox Dohzono
Hisao Aoyama <aoy...@astec.co.jp> writes:
> In article <9do047$27lm$1...@news2.rim.or.jp>
> doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
>
> > | t->tm_mday++;
>
> tm_mday が 32 になってしまったら，というのは気に
> しなくて良いのでしょうか?
はい, 構わないはずです.
7.23.1 Components of time
…
int tm_mday; // day of the month -- [1, 31]
…
7.23.2.3 The mktime function
…
Description
[#2] The mktime function converts the broken-down time,
expressed as local time, in the structure pointed to by
timeptr into a calendar time value with the same encoding as
that of the values returned by the time function. The
original values of the tm_wday and tm_yday components of the
structure are ignored, and the original values of the other
components are not restricted to the ranges indicated
above.
…
Atushi Sakauchi
At 14 May 2001 16:49:19 +0900,
Hisao Aoyama wrote:
>
> Hisao Aoyama <aoy...@astec.co.jp> writes:
> tzset() と mktime() の間に，day light saving が
> 終わったら/始まったらどうする，とい話はありますね．
tzset();
utc_tm->tm_isdst = 0;
desired_result = mktime(utc_tm) + timezone;
では，まずいですかね？
> 一方，
>
> In article <9do047$27lm$1...@news2.rim.or.jp>
> doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
>
> > | t->tm_mday++;
>
> tm_mday が 32 になってしまったら，というのは気に
> しなくて良いのでしょうか?
規格上，気にしなくて良いはずです．
ただいずれにしても，(歴史的に)timezone の値が変化するような，
zoneinfo が設定されていると，まずい場合がありそうです．
Kazuo Fox Dohzono
doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
> The
> original values of the tm_wday and tm_yday components of the
> structure are ignored, and the original values of the other
> components are not restricted to the ranges indicated
> above.
もうちょっと後まで書いた方がいいかな.
On successful completion, the values of the
tm_wday and tm_yday components of the structure are set
appropriately, and the other components are set to represent
the specified calendar time, but with their values forced to
the ranges indicated above; the final value of tm_mday is
not set until tm_mon and tm_year are determined.
matsunaga
特に下記関数は大変参考になりました。
time_tがローカル時間Jan 1 00:00 1970 からの秒数、
と言うのは暗黙の了解のようですね。
"Kazuo Fox Dohzono" <doh...@hf.rim.or.jp> wrote in message
news:9do047$27lm$1...@news2.rim.or.jp...
Kazuo Fox Dohzono
"matsunaga" <matu...@rd.casio.co.jp> writes:
> time_tがローカル時間Jan 1 00:00 1970 からの秒数、
> と言うのは暗黙の了解のようですね。
eopch は別に上記の通りでなくとも良いと思うんですが,
7.23.2.4 The time function
…
Description
[#2] The time function determines the current calendar time.
The encoding of the value is unspecified.
なので
> > | timet = (time_t)0;
がシステムの spoch time とは限らない可能性はありますかね.
Takashi SHIRAI
In article <9do048$27lm$2...@news2.rim.or.jp>,
Kazuo Fox Dohzono <doh...@hf.rim.or.jp> wrote:
>> tzset();
>> desired_result = mktime(utc_tm) + timezone;
>>
>> といった感じでしょうか?
>
>夏時間を考慮する必要がありますね.
じゃあ閏秒も．．．。
＃ ちゃんとまめに閏秒の設定をしている管理者って一体どのくら
＃いいるのかしらん？既に 30 秒程度の差がついてる筈です。
--
しらい たかし
matsunaga
> In article <9do9ep$lcp$1...@news.casio.co.jp>
> "matsunaga" <matu...@rd.casio.co.jp> writes:
>
> > time_tがローカル時間Jan 1 00:00 1970 からの秒数、
> > と言うのは暗黙の了解のようですね。
>
> eopch は別に上記の通りでなくとも良いと思うんですが,
(time_t)0の表す日付に関しましては、仰る通りで、
time_t同士で加減算出来る事が暗黙の了解なのかな、と思っていたのですが、
7.23.1 Components of time
<snip>
time_t
which are arithmetic types capable of representing times;
と、arithmetic type
とありますので、加減算出来るものと解釈しても良いのでしょうかね、、
Atushi Sakauchi
At Mon, 14 May 2001 21:19:02 +0900,
Takashi SHIRAI wrote:
>
> しらいです。
> >夏時間を考慮する必要がありますね.
>
> じゃあ閏秒も．．．。
POSIXでは，閏秒を考慮しないことになっているようです．
手元の JIS X3030-1994 の 2.2.2.77 には
『基準時点からの通算秒の値を協定世界時(UTC)名で表すと，
次のとおりとなる．
tm_sec+tm_min×60+tm_hour×3600+tm_yday×86400+(tm_year-70)×31536000+
((tm_year-69)/4)×86400』
という記述があります．
つまり POSIX の time_t を引き算して経過時間を計算すると，閏秒の分だけ
誤差が出ることになります．
FreeBSD の場合は，この time_t と，閏秒を考慮した time_t の変換のために
time2posix(), posix2time() という関数があります．
また，FreeBSD と Linux では，zic コマンドに -L オプションをつけて
/etc/localtime を作り直すことで，標準関数が閏秒を考慮するようにも
できました．
Takao Ono
matu...@rd.casio.co.jpさんは書きました。
matunaga> (time_t)0の表す日付に関しましては、仰る通りで、
matunaga> time_t同士で加減算出来る事が暗黙の了解なのかな、と思っていたのですが、
matunaga> 7.23.1 Components of time
....
matunaga> とありますので、加減算出来るものと解釈しても良いのでしょうかね、、
integer type と floating type を総称して arithmetic type (6.2.5,
paragraph 18) ですから, time_t が arithmetic type であると言って
いる以上 integer type か floating type のいずれか (どれかは実装依
存) なわけで, つまりは加減算可能でしょう.
ただし, time_t の 1単位がどのくらいの時間になるのかわからない (そ
のための difftime) ので, 加減算した結果が意味を持つのかどうかよく
わからないんですけど.
# ん～, time と clock の違いって....
--
名古屋大学 工学部 電子工学科 平田研究室
小野 孝男
Toshiboumi bugbird Ohta
Takashi SHIRAI wrote:
<snip>
> ＃ ちゃんとまめに閏秒の設定をしている管理者って一体どのくら
> ＃いいるのかしらん？既に 30 秒程度の差がついてる筈です。
「偉大なる三要素」をもってすれば、何も考えずに ntp を
使うに一票。
# そんな「まめ」な管理者がいるネットワークでは暮らしたく
# ないなぁ
--
timedia [+81-3-5362-9009] % finger bug...@timedia.co.jp
Login: bugbird Name: User Bugbird Toshiboumi Ohta
Directory: /network/admin Shell: /bsd/tcp/mac/midi
On since Sat Aug 20 19:55 (JST) on tyo from mama.and.papa
Kazuo Fox Dohzono
shi...@nintendo.co.jp (Takashi SHIRAI) writes:
> じゃあ閏秒も．．．。
先輩からのメイルではちゃんとその辺りも言及されていたのですが, 「閏秒ま
で考慮するのはやりすぎ」という意見だったので割愛しました (そういう値が
必要なアプリケーションで対応すればよいのであって, 素朴なラーメンタイマー
が 1 秒狂ったりする :-) ので由々しき問題だ, とか).
# ちなみにそのメイルは「なんで tm_mon が [0, 11] なのか」という私の疑
# 問から始まった話でした.