2010年05月15日

OAuth への道―― HMAC-SHA1, Base64, URL Encode

-------------------- HMAC-SHA1 + Base64 でシグネチャーを作る -------------------------

さて、以前にも書いたとおり、この周辺の処理は理解できませんでした……で、ソースを
入手しました。

http://www.koders.com/c/fid645718469E4742143926FA6138FC7FD33BBD3A4F.aspx から入手しました。
使用したのは、base64.h base64.c hmac.h hmac_sh1.c memxor.h memxor.c sha1.h sha1.c です。


Windows の処理系で、かつ、C++で動かそうとすると、いくつかの変更が必要になります。
まず、

・各ソースに含まれている #inlcude は削除します。
 これは、unix 環境でファイルの依存関係などを記述するファイルらしいです。
 が、そもそも、config.h が入手できなかったのと、実際には、なくてもコンパイルできるので、これはあっさりと削除します。

・いくつかのソースにある、restrict を削除します。
 これは、C99 で定義された予約語で、関数の引数として渡された領域が「重なっていない」とコンパイラに仮定させるものです。
 標準の C++ では、まだ定義されてないので、これまた、あっさりと削除します。

さて、実際に、HMAC-SHA1 および、BASE64 でシグネチャーを作成します。

以上のファイルがそれぞれコンパイルできる状態で、

void makeSign(const char *inBuff, char *key, char *outBuff)
{
int inLen = std::strlen(inBuff);
int keyLen = std::strlen(key);
char resBuff[1024];

hmac_sha1 (key, keyLen, inBuff, inLen, resBuff);
base64_encode (resBuff, 20, outBuff, 64);
}

これで、inBuff から始まる文字列を、key という文字列で、ダイジェストし、Base64 で変換したものを、outBuff 以降に保持します。

ただし、実際に使用する際には、もう一段、URL Encode が必要です。

-------------------- URL Encode -----------------------------

URL Encode はそんなに難しい処理ではないので、自力で作りました。
もともと、inBuff と URL Encode して、outBuff にセットするというものです。
3番目の引数の、delChar は、別の用途に使い回したくて、つけています。
これは、URL Encode が必要な文字に対して、%xx とエンコードするのではなくて、「削除」します。
たとえば、

abc+def=ghi

を普通にエンコードすると
abc%26def%3Dghi

ですが、delChar = true; にして呼び出すと、
abcdefghi
とエンコードすべき部分を削除します。

これは、oauth_nonce に使い回すためです。
oauth_nonce は、「POSTごとにランダムな文字列」が要求されますが、ランダムな「文字列」を簡単に作るには、せっかくある、HMAC-SHA1 を使うのが早いと、そういう発想です。
実際には、
Base Strign = "2010/05/15-15:00:00" と時刻から生成し。
key = "1000000" → "1000001" → "1000002" と、POST ごとに+1した数値(を文字列にしたもの)
を使って、oauth_nonceを生成しています。
ただ、この中に、エンコードできる文字が入ってしまうと、ちょっと面倒なので、なら、エンコードできる文字は「削除」という発想でした。


void URLEnc(const char *inBuff, char *outBuff, bool delChar)
{
char *nonEscape = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.~";

std::string line = "";
while(*inBuff)
{
char c;
char lBuff[16];
std::string orgLine = "";

c = *inBuff++;

if (std::strchr(nonEscape, c))
{
lBuff[0] = c;
lBuff[1] = '\0';
}
else if (! delChar)
std::sprintf(lBuff, "%%%02X", c);
else
lBuff[0] = '\0';

line += lBuff;
}

std::sprintf(outBuff, "%s", line.c_str());

}


こんな感じで、HMAC-SHA1 → BASE64 → URL エンコード と処理を進めることができました。
posted by 麻野なぎ at 15:27| Comment(0) | TrackBack(0) | Twitter と Bot の周辺

2010年05月14日

OAuth への道――具体的な送信内容

さて、Bot 限定でなんとか、必要なキーを入手することができました。
入手できたキー情報は4個
Bot の場合、キーの入手がかなりお手軽なので本当に助かりました。

Consumer key: aaaaaaaaaaaaaaaaaaaaaa
Consumer secret: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
Access Token: cccccccccccccccccccccccccccccccccccccccccccccccccc
Access Token Secret: ddddddddddddddddddddddddddddddddddddddddddd

※このキーは架空のものです。もうちょっとそれらしいものをでっち上げたかったのですが……。

これをもとに、ヘッダを作成します。

必要な処理は

・URL Encode …… とりあえず自作。
・HMAC-SHA1 および、BASE64 によるシグネチャーの作成 …… ソースを取ってきました。
・Unix Time の算出 …… とりあえず自作。Turbo C++ にある、TDateTime 型から変換。

私の場合、「節気さんシリーズ」を動かすことが目的なので、とにかく、POST ができればいいという、そういう方針でまいります。

【HTTP ヘッダ】

POST http://api.twitter.com/1/statuses/update.xml HTTP/1.1
Host: api.twitter.com
Content-type: application/x-www-form-urlencoded
Authorization: OAuth oauth_nonce="777ccc777",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1273672200",
oauth_consumer_key="aaaaaaaaaaaaaaaaaaaaaa",
oauth_token="cccccccccccccccccccccccccccccccccccccccccccccccccc",
oauth_signature="xxxxxxxxxxxxxxxxxxxxxxxxxxx%3D",
oauth_version="1.0"
Content-Length: 135

※上記の oauth_nonce= から、 oauth_version="1.0" までは実際には一行です。(改行は入りません)

oauth_nonce="777ccc777",
―― ランダムな文字列です。このあとの、timestamp と併せて、リクエストの一意性を確保するためです。

oauth_signature_method="HMAC-SHA1",
―― シグネチャーの生成方式で、Twitter では、これに限定されます。

oauth_timestamp="1273672200",
―― リクエストを発行した時刻です。Unix Time とよばれるもので、
1970年1月1日00:00:00(UTC)からの通算秒です。
      この時刻から、5分間は有効らしいです。
      あとで第三者に「再利用」されないための処置です。

oauth_consumer_key="aaaaaaaaaaaaaaaaaaaaaa",
oauth_token="cccccccccccccccccccccccccccccccccccccccccccccccccc",
―― これは、既に入手しているキーになります。

oauth_signature="xxxxxxxxxxxxxxxxxxxxxxxxxxx%3D",
―― これが、シグネチャーでして、まあ、鬼門だと思います。

oauth_version="1.0"
―― これも、現時点では、1.0 に固定です。

【先に、HTTP Body の方を……】

Twitter に投稿するための、「投稿内容」です。
実は、シグネチャーの生成には、この内容も含まれます。

status=(UTF-8 で書いたものを、ERL エンコードした文字列)

です。

ここでは、簡単に

status=abcd

としておきます(これだと、実質的にエンコードの必要がない)

【シグネチャーの生成】

さて、いよいよ、シグネチャーの生成です。
シグネチャーは、「Base String」を、「key」によって、HMAC-SHA1 で変換したものを、さらに、BASE64 で変換したものです。

● Base String とは……

ここでは、POST 処理を考えていますので、

POST
&
http%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses%2Fupdate.xml
&
oauth_consumer_key%3Daaaaaaaaaaaaaaaaaaaaaa
%26
oauth_nonce%3D777ccc777
%26
oauth_signature_method%3DHMAC-SHA1
%26
oauth_timestamp%3D1273672200
%26
oauth_token%3Dcccccccccccccccccccccccccccccccccccccccccccccccccc
%26
oauth_version%3D1.0
%26
status%3Dabcd

となります。
実際には、これを改行無しで1行にしたものです。
所々見えている、%3D は = を、%26 は、& をそれぞれ URL Encode したものです。
また、そのまま & になっている部分もあります(POST の直後と、http://api.twitter/1/statuses/update.xml の直後)

あと、順番にも注意が必要です。パラメータがアルファベット順に並ぶようにします。(この順番はそうなっています)

● Key とは……

ここまで使っていなかった、secret の出番です。
キーは、Consumer secret と Access Token Secret を & でつないだものです。
つまり、

bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb&ddddddddddddddddddddddddddddddddddddddddd

がキーになります。

● これを、HMAC-SHA1 と BASE64 で整形する。

実際の処理は、理解できませんでした。
ソースを、 http://www.koders.com/c/fid645718469E4742143926FA6138FC7FD33BBD3A4F.aspx から入手しました。
使用したのは、base64.h base64.c hmac.h hmac_sh1.c memxor.h memxor.c sha1.h sha1.c です。

この例で計算すると、 lJdZXD19quOrpHsxMzfaM0WWkW8%3D になるようです。

急ぎ足ですが、まずは、一通りやってみたところで。
posted by 麻野なぎ at 23:54| Comment(0) | TrackBack(0) | Twitter と Bot の周辺

深夜のメールは「マナー違反」だという説

深夜のメールは「マナー違反」といわれたが?

こんな質問が上がっているのをみて、回答してみたのだけれど……。
ほかの回答をみると、携帯電話でメールに対して着信音が鳴るのが迷惑だから……という発想らしい。

しかしながら、もともとインターネットや、かつての、パソコン通信にしても、メールというのは、いつでも好きなときに送信できて、いつでも好きなときにそれを読むことができるというメディアだったのではなかったか。

それが、携帯電話によるメールが浸透してきて、どうも、メールに即時性(というか、即応性)が求められてきている気がする。
それでも、携帯電話でメールが使えるようになったときには、既に電子メールというものは存在して、使われていた。そして、携帯電話から、インターネットへの接続性を確保したという歴史の流れを考えるなら、既に使用されていた「文化」を尊重すべきではあったかと思う。

それにしても、携帯電話から入って、自分の使い方に沿わなければ、その時点で「マナー違反」という言葉が出てくるのも、いかがなものかなと思う。「自分にとっては迷惑だから配慮を求める」というのと、「マナー違反だ」というのは、基準としてずいぶんと異なるのだし、かなり広い範囲を把握しなければ、「マナー違反」という表現は、(本来)難しい。

さて、ここまで考えて、なぜ、そもそもメール着信に、「着信音」が存在するのかと考えた。通話であれば、確かに着信音は必要で、着信音が鳴れば、すぐに出るか、少なくとも相手先を確認しなければならい。そして、だからこそ、「通話」に対しては、深夜は遠慮しろとか、受ける方も、必要に応じてマナーモードにせよとか、それこそ、「マナー」と考えられるようなことがある。

一方、メールに対して、着信音が鳴ったから、即メールを見るという行動がどの程度一般的なのだろう。「仕事の関係でメールを携帯電話に転送している」人だって、まさか、お客様と商談中に、「ちょっと失礼」という行為はしないだろう。
結局、移動中だとか、商談の間だとか、「自分で確保できた時間」のなかでメールを読むことになる。

だったら、多分、メールに対しては本来着信音は不要なのだ。
では、なぜ、「深夜のメールはマナー違反」といわれるほど、みなが、メールに対して着信音を設定しているのだろう。
かくいう私も、しばらくはメール着信音を設定していた。
それがあまりうるさいので、着信音を「無音」にして、そして、家族とアラーム的に使っているメールについては、個別設定でそれぞれ別々の着信音を設定している。

もしかしたら、携帯電話の初期状態でメール着信音が鳴るように設定されているのが大きな要因かもしれない。
さらにいえば、メール着信音の初期状態が、「通話の着信音と同じ」に設定されているケースもあった。
確かに、夜中、通話と同じ着信音で飛び起きれば、何のことはないメールだったというのは迷惑な話だろう。
でも、その、メール着信音、そもそも必要ですか?
posted by 麻野なぎ at 12:27| Comment(0) | TrackBack(0) | 雑感

2010年05月10日

OAuth への道――Bot 用、Access Token、Access Token Secret 入手法

さて、Twitter の Basic 認証終了が迫りました。
節気さんシリーズは、現在 Basic 認証で動いているので、なんとか、6月中に OAuth に対応させなければなりません。
しかも、この Bot C++で動いているので、なんか、かなり自分でコードを書かなければならない雰囲気。
(とりあえず、HMAC-SHA1 の部分は、なんとかコードを探してくることにしますが……)

そこで必要になる情報が、アプリケーション(Bot プログラム)側で2つ。Consumer key と Consumer secret。
Bot のアカウント側で2つ。Access Token (oauth_token) と、Access Token Secret (oauth_token_secret) 。

前者の2個は、アプリケーション登録時に、その情報として得られるので良いのですが、後者の2個はちょっと難しい。
もともと、OAuth 自体が、アプリケーション(クライアント)側に、自分のパスワードを知られずに、機能を委譲するというものなので、アカウント側の情報を得るのは、ある程度面倒な使用になるのは仕方ないのですが。

ところで、Bot の場合、事情はかなり特殊です。
・そのアプリケーションは、Bot としてのポスト(など)にしか使用されない。
・Bot のアカウント自体も、もともと、プログラム作成者(=アプリケーションの登録者)が管理している。
ということで、やはり、Bot であれば、アカウント側の情報も簡単に入手する方法があったのでした。

1.http://dev.twitter.com/ を開く
2.(2)Register an app をクリックして、アプリケーションの登録(既に登録してあれば次に)
3.Bot のアカウントでsign in する
4.アプリケーションの登録作業
5.この時点で、Consumer key, Consumer secret が取得できる。
6.My Account Token をクリック
7.Access Token (oauth_token) と、Access Token Secret (oauth_token_secret) が取得できる。
 (同時に、該当アカウントの、設定 → 外部アプリ に、このアプリケーションが登録されている)
8.忘れずに、sign out

こんなところで、OAuth に必要な情報はとりあえず、すべて揃います。
あとは、これを、加工して認証まで持って行くことになります。

あとはまた。
posted by 麻野なぎ at 22:28| Comment(0) | TrackBack(0) | Twitter と Bot の周辺

2010年05月09日

「立派な犯罪です」という表現

たとえば、「万引きは立派な犯罪です」という表現がある。
この表現に対して、時として「犯罪を、立派などと表現するとはどういうことだ」というクレームがつくケースがあるらしい。
「立派な」という単語自体は、形容動詞で
・堂々としていて正しいようす。いかめしく見事なようす。また、技術・能力などがすぐれているようす。
・とやかく言う所がなく完全であるようす。
という2つの意味を持っている。(いずれも、『学研国語大辞典(第2版)』

冒頭の例は、後者の用例であり、「間違いなく、明らかに犯罪である」ということを意味している。
後者の意味に気づかなかった場合、不自然な意味だと感じられるわけである。

と、ふと考えてみた。たとえば、「万引きは立派に犯罪です」と表現したら、おそらくクレームはつかないだろう。
この違いは何によるのか? そもそも、この表現は正しいのか?

さて、少々調べてみると、立派なという単語は形容動詞である。
そして、「立派な犯罪です」というケースでは連体形であり、「立派な」は直接名詞である「犯罪」を修飾する。
これに対して、「立派に犯罪です」のケースでは、連用形であり、助動詞の「です」にかかる。
つまり、「明らかな事実です」というニュアンスとなる。

だから、「立派に犯罪です」であれば、後者の意味が強調され、誤解の余地も少ないと、そういうことのなのだと納得した次第である。
posted by 麻野なぎ at 20:04| Comment(0) | TrackBack(0) | 雑感・ことば

2010年05月03日

お知らせ――「松江の節気」の ID を変更しました。

節気さんシリーズの Bot のうち、「松江の節気」だけが、sekki_twit_bot という、他とはかけ離れた名前になっていました。
今般他のBotと統一するため、sekki_matsue に変更しました。

既にフォローいただいている場合には、何も変更は不要です。
また、@sekki_twit_bot というページも残している(というか、実際には、ID変更後、新たに作った)ので、こちらにいってしまった場合には、sekki_matsue のほうをフォローいただければと思います。

2010年04月30日

Twitter の「嘘」

いえ、タイトルはちょっと過激につけてみましたが、それほどのものではありませんので、はい。

一般的に、Twitter を「使っている」立場のイメージは、

・気楽なつぶやきを投稿
・気に入った人があれば、フォローする。
・そうすると、フォローした人のつぶやきが「飛び込んで」くる。
・そうして、自分と、フォローした人たちのつぶやきが、「タイムライン」を流れていってしまう。。

こんなところだと思います。
さて、実は、自分の「つぶやき」が、かなり長い間保存されていて、しかも、だれにでも――Twitter のアカウントを持っていない人であっても――見られるということを、意識する機会は少ないのではないでしょうか?

実際、buzztter で検索することも可能ですし、google の検索にも引っかかります。
(自分で、検索することできます)

通常のブログであれば、ユーザーサイドでも、「書かれたものは消さない限り、保存・公開される」というのが、意識できる構造になっています。
一方で、Twitter は、「タイムライン」を見る限り、つぶやきは、どんどん流れていってしまう――と、そう感じられるのが、もしかしたら、その「つぶやき」が、永く・広く公開されてしまっているというのを、意識しにくい形になっているのではないかと、思うわけです。

※ただし、「自分のつぶやきを公開しない」設定であれば、一般的な検索には引っかかりません。

既に、「自宅を留守にします」とつぶやいたら、泥棒に入られたという事件も発生していますが、
http://www.ideaxidea.com/archives/2009/06/twitter_robery.html

もしかしたら、Twitter というのは、その、「感じ方」と「波及効果」の間に、かなりのギャップがあるのかもしれません。


【ここから、若干技術的なお話】

技術的には、「どんなデータを使うか」ということと、「そのデータをどう見せるか」というのは、個別に考えることです。
データは同じものであっても、どう見せるかで、掲示板のように見えたり、Twitter のように見えたりするわけです。

実際、技術的にいえば、Twitter に対して行われた「つぶやき」は、決して、「飛び込んで」は来ません。
自分が、フォローしている人のリストを頼りに(自動的にですが)読み込んでいるだけです。

だから、Twitter の方から見ると、ポストされるより、タイムラインを「読む」ことの方が、負荷がかかります。
ですから、多くの人にフォローされても、案外、システム的には平気なのですが、多くの人をフォローすると、システム的に結構きついことになります。(なので、フォローする数は制限がある)

このあたり、「どう見せるか」という点をよく考えられたシステムだと思います。
ただ、通常のユーザーサイドの感じ方を超えた、検索が可能なところは、若干、疑問を感じないでもありません。


posted by 麻野なぎ at 13:21| Comment(0) | TrackBack(0) | Twitter と Bot の周辺

Twitter における Bot (API) のポスト数制限

さて、公式の資料(たとえば http://help.twitter.com/entries/15364 )によれば、

> Updates: 1,000 per day. The daily update limit is further broken down into smaller limits for semi-hourly intervals. Retweets are counted as updates.

となってます。
ここで、Updates というのが、実際には、ポストに相当するわけですが、1日あたり、1,000ポストまで、というのが見えます。
ただ、そのあと、The daily update limit is further broken down into smaller limits ... というのが書かれているのですが、ああ、broken down ―― 壊れる? もしかして、規制が無視される例外ケースがあるんだなと、まあ、1,000ポストなんてしないから、まあ、いいや、と、そう思ったのですが。

実際の投稿数規制は、 20ポスト/30分 なんだそうです。
そこで、冷静に和訳すれば

「一日あたり、1000ポスト。この制限は、同じ比率で、30分間隔で判断される」
ということで、1000ポスト/日 = 41.6ポスト/時 = 20.5 ポスト / 30分 となりまして、実際には、この数値でカウントされているということです。

実は、ここで動かしている Bot に、「50地域の日の出君」と「50地域の月の出君」というものがあります。
その名の通り、日の出・日の入り(そして、月の出・月の入り)の時刻に、つぶやくわけです。それもまた、 名前の通り、50地域を担当しています。

この設定だと、季節によって、短い時間にポストが集中してしまうわけですね。実際、2010年4月27日に、04:28:47 - 05:08:30 の約30分間に、25個のポストをして、そこで、制限に引っかかりました。

結局、同じような時刻のポストをまとめるようにして、この制限を回避しました。こんな感じ。

【旧バージョン】
4:28:47 《稚内》    日の出
4:34:52 《札幌》    日の出
4:41:35 《青森》    日の出
4:41:54 《盛岡》    日の出
4:45:29 《仙台》    日の出
4:46:00 《秋田》    日の出
4:47:35 《山形》    日の出
4:47:56 《福島》    日の出
4:50:08 《水戸》    日の出
4:52:13 《宇都宮》   日の出
4:52:48 《千葉》    日の出
4:53:25 《新潟》    日の出
4:54:14 《東京》    日の出
4:54:16 《さいたま》  日の出
4:54:53 《横浜》    日の出
4:55:45 《前橋》    日の出
4:56:28 《小笠原》   日の出
4:58:52 《長野》    日の出
4:58:54 《甲府》    日の出
5:00:41 《静岡》    日の出
5:02:40 《富山》    日の出
5:05:08 《金沢》    日の出
5:06:15 《名古屋》   日の出
5:06:27 《岐阜》    日の出
5:07:39 《福井》    日の出
5:08:30 《津》     日の出
以上 26ポスト/30分


【新バージョン】
4:29:00 《稚内》        日の出
4:36:00 《札幌》        日の出
4:42:00 《青森》・《盛岡》   日の出
4:45:00 《仙台》        日の出
4:46:00 《秋田》        日の出
4:48:00 《山形》・《福島》   日の出
4:50:00 《水戸》        日の出
4:52:00 《宇都宮》       日の出
4:53:00 《千葉》・《新潟》   日の出
4:54:00 《東京》・《さいたま》 日の出
4:55:00 《横浜》        日の出
4:56:00 《前橋》・《小笠原》  日の出
4:59:00 《長野》・《甲府》   日の出
5:01:00 《静岡》        日の出
5:03:00 《富山》        日の出
5:05:00 《金沢》        日の出
5:06:00 《名古屋》・《岐阜》  日の出
5:08:00《福井》         日の出
5:09:00 《津》         日の出
以上 19ポスト/30分


posted by 麻野なぎ at 13:03| Comment(0) | TrackBack(0) | Twitter と Bot の周辺

2010年04月18日

節気さん Bot の憂鬱

まあ、タイトルほど大げさな内容ではないのですが
まず、節気さん Bot の紹介から。
Twiter 向けに、そういう Bot を書いております。

詳しくは、
http://www.nagi.asano.name/twit_bot.html
をご覧いただけばと思います。

また、具体的につぶやいている内容は、
http://twitter.com/asano_nagi/sekki-series
のリストで確認いただけるかと。

さて、この Bot ですが、実は、Twitter のリアルタイム性に着目したものです。
もともと、二十四節気の該当日に、それをつぶやくということからスタートしたのですが、この、二十四節気、単に、「今日は(たとえば)夏至です」というだけではなく、「今日のxx時xx分が夏至です」という、時刻まで定義されているものです。
そういうわけで、その時刻に、「ただいま夏至です」というつぶやきをする、というコンセプトで始まったわけです。

そうすると、二十四節気の正確な時刻が必要なわけですが、これは、国立天文台の「暦要項」というページ
http://www.nao.ac.jp/koyomi/yoko/
で入手できます。

この Bot も当初、このページから入手した情報を元に、つぶやきのタイミングを決めていました。

さて、本日、二十四節気のタイミングを、Bot のプログラム内部で計算するように変更しました。
もっとも、内部で計算しましたといっても、本質的には、『日の出・日の入りの計算』(長沢工著、地人書館)の内容を流用しているわけですが。

この計算式は、非常に精度が高く、おおむね30秒くらいの精度で、二十四節気の時刻や、新月・満月の時刻などを算出できます。
それでも、数秒の誤差が、(つぶやくときの、時刻表示が分単位なので)見かけ上1分の誤差になることがあります。
結果的に、わざわざプログラム内部で時刻を計算して、それが、国立天文台の発表と異なるという結果になります。

ここで、苦労して自力で計算するよりも、天文台の発表をそのまま使った方が良いのではないか? むしろ、そのまま使うべきではないのか? と、そういう思いに悩まされるわけであります。

まあ、そう悩みながらも、やっぱり、「自分で計算してみたい」という欲求から、本日から、「自力計算バージョン」で出発するわけですが。

【時間区切りの怖さ】

さて、ここまでは、計算結果に数秒〜30秒以内の誤差があり得る、それが、見かけ上1分の誤差になって表れるというお話でした。
ただ、「時間区切り」というものがあるので、本当は、もっと恐ろしい誤差が出る可能性があります。
たとえば、冬至が、ある年の 12/20 25:59:58 などというポイントで発生するとしましょう。わずか5秒の誤差で、12/21 00:00:03 秒が、冬至であるという計算結果が出かねません。
そうすると、世の中より、1日遅れて、「今日は冬至です」というつぶやきをしかねないのです。

冒頭の、「1分の誤差」は、なんと言っても、「国立天文台の発表に対して、数分の誤差はあります」といって、認められる範囲だと思いますが、「今日は冬至です」が、翌日になってしまったら、ちょっと様にならないなぁと思うわけであります。

ま、ここ数年は、こんなシビアなタイミングはないようですが。

時間区切りという話では、関連して、「日本と中国における旧暦の日付がたまに、1日異なる」という現象も発生します。
これは、日本と中国の時差が1時間あることと、旧暦の「(その月の)1日は、朔(新月)の瞬間を含む日」という定義の関連です。
つまり、日本時間の午前0時から1時の間に朔の瞬間があると、中国時間では、まだ前日ということになります。
つまり、日本時間1月10日の午前0:30 が朔の瞬間であれば、1月10日が日本における旧暦の1日(ついたち)となります。
しかしながら、中国では、その瞬間1月9日なので、1月9日が、中国における旧暦の1日になるわけです。
さらに、ベトナムあたりまで範囲を広げると、旧暦の「月の決め方」の関係で、(旧暦における)新年が、一ヶ月近くずれると言うこともあるようです。
posted by 麻野なぎ at 16:49| Comment(0) | TrackBack(0) | Twitter と Bot の周辺

2010年04月14日

500円玉と10円玉のお話

これまたどこかで聞いたお話。
ある施設の少女。彼女に取っては、500円玉より、10円玉の方が価値があるのだという。
なぜなら、10円玉があれば、その施設の赤電話で大好きなお母さんに電話ができるから。

本当にこの通りだったか、あるいは、話者の意図はどうだったか、不確かな面もありますが。

これを読んだとき、「ああ、500円玉の方が価値があるに決まっている」などと、こちらの価値観を押しつけてはいけないのだなと思いました。
でも、ちょっと待て?

実際には、500円玉の方が価値があります。もちろん。
なぜ、だれも、彼女に「一枚の500円玉は、50枚の10円玉になるんだ」と教えなかったのでしょう。
悪意で考えれば、「お母さんの声が聞こえる」といって、500円玉を渡すべきところで、10円玉を渡すようなことも考えられます。

本当にすべきなのは、「今すぐにお母さんの声を聞くには10円玉」ということではなく、「ちょっと手間はかかるけど(両替しなければならないから)500円玉は、10円玉50枚になる」と教えることなのではないかと思うわけです。

さて、そしてこれは、なにも、彼女だけのことではありません。
私たちは、往々にして、「今までできていたやり方」「今やっているやり方」に固執しがちです。
もしかしたら、「両替する」という手間を惜しんで、10円玉をかき集めているのは、私たち自身なのかもしれません。
posted by 麻野なぎ at 21:32| Comment(0) | TrackBack(0) | 雑感