銀杏の木

さくらのレンタルサーバには pear がインストールされているのだが、権限がないのでパッケージを追加するなど操作することが一切できない。

それでは全く使いものにならないので、自分で pear をインストールする方法をネットで手順を検索してみたのだが、「 pear の公式サイトの go-pear はうまく動作しなくなっていてエラーが出るので（そのサイトに独自に）保存してあるアーカイブをダウンロードしてインストールする」とか、「 go-pear.php をダウンロードして実行する」とか、なんだか変なことばかり書いてあるので、参考にするのはやめて、 pear の公式サイトをたどってみた。

pear の公式サイトの url を開き、「installing PEAR on your system」のリンク先を開き、「Getting and installing the PEAR package manager」のリンク先を開く。

すると、「Unix/Linux/BSD」のセクションに、

とするように書いてある。特に問題もなく go-pear.phar がダウンロードされ、実行する。

このような選択肢が表示されるので、 all を選択すると、１から１２まで順番にディレクトリを設定することになる。基本的に提案されて表示された通りのディレクトリで問題ないが、 Public Web Files directory だけは、提案通りに入力すると $prefix/www となってしまう。提案通りの $prefix を入力していある場合、 /home/（ユーザID）/pear/www となるのでそれではまずい。 /home/(ユーザID）/www と入力しなければいけない。

１から１２までの入力を完了すると、先程の選択肢の表示に戻るので、今度は ENTER だけ入力すると、インストールが始まる。設定内容は /home/（ユーザID）/.pearrc に保存される。

と WARNING が表示されるので、さくらのレンタルサーバのコントロールパネルを開き、「アプリケーションの設定＞PHP設定の編集」を選択し、エディットボックス内に、

と入力し「保存する」ボタンを押し保存しておく。

先程の go-pear.phar の設定の続きに話を戻すと、その後、

と聞かれるが、 Y と返事しても、 /usr/local/php/7.3/etc/php.ini は、レンタルサーバのユーザからは編集できない（だからレンタルサーバのコントロールパネルに編集する場所がある）ので、ここは N と答えておく。

などと、ちょっと文句を言われるが気にしない。

と警告されるが、自分のサーバの場合はどちらの pear を実行して pear list としてみても PEAR のバージョンに変化がないので問題はなさそうだ。気になる場合は /home/（ユーザID）/pear/bin を PATH に追加しておくとよい。その際は、 /usr/local/bin/pear よりも優先して実行されるようにしておくこと。

以上が、さくらのレンタルサーバに pear をインストールする手順だ。なぜか、ネットに上がっているさくらのレンタルサーバへの pear のインストール方法には、このようにしてインストールすると書いてあるサイトが皆無だった。一体どうしてなのだろう？そもそも go-pear.php ってなんだ？そんなファイルなかったぞ？？ go-pear.phar の間違いなのか？それにエラーもなく普通にインストール、実行できるのだが・・・。

date_default_timezone_set() でタイムゾーンを指定できることが分かったので、 strftime(), gmstrftime() にタイムゾーンを反映させた。

それにともなって、スキンの Date タグのオプションとして、 timezone を追加した。サーバに設定されているタイムゾーンのまま変更が不要の場合は、このオプションを指定しなければよい。

pubDate の出力の場合は、

のように指定することで GMT で日時を出力することができるようになった。

これで一応は、 RSS2.0 の記事の公開日時（ pubDate ）では GMT で出力するようにしながら、各スキンでの処理ができるようになった。

ただ一つ気になるのは、date_default_timezone_set() の結果がプロセス全体に反映されるため、 PHP に同時に多数のアクセスがあった場合に、もし各アクセスがスレッド単位で処理されるとしたら、この関数によるタイムゾーンの変更が、別のスレッドで動作中の処理に予期しない影響を与えることになるのだが、大丈夫なのかな？

rNote の rnote_config.php の初期設定では、

と書かれているのだが、これだと setlocale() がエラーでこける。

サーバのコンソールで locale -a で見てみると、ja_JP.UTF8 ではなく ja_JP.UTF-8 だったので、同じ記述になおしたところ setlocale() が通るようになった。サーバによって　jp_JP.UTF-8 だったり、 ja_JP.UTF8 だったりするのだろうか？

ちなみに、 setlocale(LC_ALL, "ja_JP.UTF-8"); を実行した返り値を見ると、

となっている。両端のダブルクォーテーションとドットはなんだろう？

予想としては、

のような形で返ってきて欲しかったのだが・・・。百歩譲ってダブルクォーテーションで括られているのはよいとしても、ドットの意味が分からない。まあ、この返り値をどうこうするつもりはないので、エラーでないことが分かれば中身はどうでもいいのだが。

次に、

ただ、 "ja_JP.utf8" を、英語表記にするために "en_US.utf8" としたら、時刻もずれてしまう。

についてだが、どうやら strftime() の時刻に関しては setlocale() で en_US.UTF-8 と指定しても日本時とずれないようだ。そして、 gmstrftime() という今回の用途にぴったりの関数もあることが分かった。これを使えば、

どうしようもないので、 setlocale() に失敗するサーバの場合の処理として、記事の UNIX タイムスタンプから、予め定義しておいた定数分だけ固定で差し引きし strftime() に渡すようにした。時差を表す表記部分も、 %Z が指定されていたら GMT に置き換えるようにした。なんのための setlocale(), strftime() なのかさっぱり分からなくなってしまったが、しょうがない。

の処理は不要になる。ただし、 %Z で指定されるタイムゾーン文字列だけは問題で、setlocale(LC_TIME, "en_US.UTF-8"); gmstrftime(); とした場合、日時は GMT での日時として出力されたが、タイムゾーンは JST と出力されてしまった。

このことからも、 strftime(), gmstrftime() は setlocale() の結果を、日時の表示形式のためにしか参照しないようだ。そして、 JST と出力されていることと、 gmstrftime() で正しい GMT での日時が出力されることから、 strftime(), gmstrftime() がタイムゾーンを考慮して日時を修正する方法は、なにか別の方法をとっているらしい。

その「別の方法」が不明なので、とりあえず今のところは %Z を GMT と置換することで対処しておくことにする。

pubDate で JST を指定し日本の現地時刻で RSS2.0 を作成した場合、 Akregator が９時間未来の記事として表示する問題について、いろいろ調べてみた。

結局、時差の指定部分は GMT でなければ日時を正常に認識しないということが分かった。

そこで、記事の日時の UNIX タイムスタンプを、 gmmktime() で一旦 GMT でのタイムスタンプに変換し、そのタイムスタンプを strftime() に渡すようにしてみたが、作成された日時に変化がなかった。

おかしいな、と思い、調べてみたところ、私の使っているサーバは setlocale() に 0 （失敗）を返すことが分かった。

setlocale(LC_ALL, 0) などとして現在のロケールを取得してみたが、帰ってきたのは "C" だけだった。

どうしようもないので、 setlocale() に失敗するサーバの場合の処理として、記事の UNIX タイムスタンプから、予め定義しておいた定数分だけ固定で差し引きし strftime() に渡すようにした。時差を表す表記部分も、 %Z が指定されていたら GMT に置き換えるようにした。なんのための setlocale(), strftime() なのかさっぱり分からなくなってしまったが、しょうがない。

とりあえず、これで Akregator は今度こそ正しい公開日時を表示してくれるようになった。

それにしても、時差の表記に GMT　しか使えないのは、 RSS2.0 の pubDate の仕様なのだろうか。それとも、RSSフィードリーダの実装上の怠慢なのだろうか。

本来ならば、読み取った時差の表記に従って、一旦 GMT での日時に変換し、起動しているフィード・リーダが現在取得したロケールでの日時に変換し表示する、という処理が正しいのではなかろうか。

ちなみに、前の記事で書いた、

そこで、ちょっと考えて、 "en_JP.utf8" と記述してみたら、見事英語で日本の時差で表示してくれた。ネットで検索しても、このような表記についての説明は皆無だったが、ロケールの表現方法が、「言語_地域.エンコード」という形式であることから試してみたのだが、 PHP7 はしっかり対応してくれていた。 PHP7 さすがである。

だが、単に setlocale() はエラーを返し、もともと英語表記だったので曜日部分も Sun と表示されただけのようだ。 ja_JP.utf8 を指定した場合に曜日部分が「日」と表示されたのは、 setlocale() の指定ができないサーバ用に自前で日本語表記に置き換えるよう rNote がもとからもっていたコードによって表示されていた。

rNote にもとから実装されている RSS1.0 では、 Dublin Core の名前空間 dc:date で日時の指定をしていた。

RSS2.0 のフィードも、同じやり方で Akregator は認識してくれたが、正しくは pubDate というタグで指定するようだ。

「RSS 2.0 Specification 日本語訳」によると、このタグは、　"Sun, 20 Jan 2019 12:00:00 JST" のような形式で日時を指定するそうなので、この要素で記事の公開日時を指定するように修正した。

rNote は、スキン内に Date タグを記述し、日時の表示フォーマットを指定することで、指定の形式で記事の投稿日時を出力してくれる。そこで、 fmt="%a, %e %b %Y %H:%M:%S %Z" とオプションを指定したのだが、出力結果の曜日が日本語の漢字で「日」と表示されてしまった。これは、 rNote 内でこの処理に使われている strftime() が、 setlocale() で設定されている現在のロケールに従って日時の表示を行うためだが、 rNote を普通に使用するとサーバのロケールが日本語に指定されるため、このような結果となる。

しかしこれではまずいので、曜日は英語の省略形式で表示しなくてはならない。

よく調べてみると、rNote のスキン用 Date タグは locale オプションも指定できるのが分かった。

ただ、 "ja_JP.utf8" を、英語表記にするために "en_US.utf8" としたら、時刻もずれてしまう。

そこで、ちょっと考えて、 "en_JP.utf8" と記述してみたら、見事英語で日本の時差で表示してくれた。ネットで検索しても、このような表記についての説明は皆無だったが、ロケールの表現方法が、「言語_地域.エンコード」という形式であることから試してみたのだが、 PHP7 はしっかり対応してくれていた。 PHP7 さすがである。

というわけで、 RSS2.0 用のスキンでの日時表示の部分は、下のようになった。

これで正しい日時をフィードリーダに伝えることができるようになった。