仕事で久々にTime::Pieceを扱っていて、localtimeの取り方がちょっと良くわからなかったので調べてみました。

事の発端はデータの時刻が一部ずれるという問題で、どうもlocaltimeへ変換するところに問題が有りそうです。実際にきているデータ例は以下のような感じ。

%Y-%m-%d %T+09:00

%Y-%m-%dT%T JST

%Y-%m-%dT%T+09:00

%Y-%m-%dT%T+0900

%Y-%m-%dT%T+9:00

%Y-%m-%dT%T-07:00

%Y-%m-%dT%T-08:00

%a %B %d %T %Y +0900

%a %b %d %T JST %Y

%a,%d %b %Y %T +0900

%a, %d %B %Y %T +0900

%a, %d %B %Y %T GMT

%a, %d %b %Y %T +09:00

%a, %d %b %Y %T +0300
※一部割愛

my $t = eval { Time::Piece->strptime($str, '%Y-%m-%d %T+09:00') } ||
        eval { Time::Piece->strptime($str, '%Y-%m-%dT%T JST') } ||
        eval { Time::Piece->strptime($str, '%Y-%m-%dT%T+09:00') } ||
        eval { Time::Piece->strptime($str, '%Y-%m-%dT%T+0900') } ||
        eval { Time::Piece->strptime($str, '%Y-%m-%dT%T+9:00') } ||
        eval { Time::Piece->strptime($str, '%Y-%m-%dT%TZ') } ||
        eval { Time::Piece->strptime($str, '%a %B %d %T %Y -0800') } ||
        eval { Time::Piece->strptime($str, '%a %b %d %T JST %Y') } ||
        eval { Time::Piece->strptime($str, '%a %d %b %Y %T -0800') } ||
        eval { Time::Piece->strptime($str, '%a,%d %b %Y %T +0900') } ||
        eval { Time::Piece->strptime($str, '%a, %d %B %Y %T +0900') } ||
        eval { Time::Piece->strptime($str, '%a, %d %B %Y %T GMT') } ||
        eval { Time::Piece->strptime($str, '%a, %d %b %Y %T +09:00') } ||
        eval { Time::Piece->strptime($str, '%a, %d %b %Y %T +0300') };
   #一部割愛

$tにはTime Zoneまで考慮された時刻が渡っているという想定です。が、実際は違ってました。

use strict;
use warnings;
use Time::Piece;

sub parse_time {
    my ($time, $format) = @_;
    my $t = Time::Piece->strptime($time, $format);
    warn $t->strftime('%Y-%m-%d %T');
}

parse_time("2012-07-12 18:00:00+09:00", '%Y-%m-%d %T+09:00');
parse_time("2012-07-12 18:00:00+03:00", '%Y-%m-%d %T+03:00');
parse_time("2012-07-12 18:00:00-07:00", '%Y-%m-%d %T-07:00');

 上記コードはタイムゾーン指定が±hh:mmな日付をstrptimeでパースして、グリニッジ標準時の時刻を返します。実際実行してみると・・

2012-07-12 18:00:00 at time-piece-test.pl line 8.

2012-07-12 18:00:00 at time-piece-test.pl line 8.

2012-07-12 18:00:00 at time-piece-test.pl line 8.

ローカルタイムゾーンが全く無視された、GMTとしての2012-07-12 18:00:00が帰ってきます。
ちなみに、こっちだと意図した結果が帰ってきます。

parse_time("2012-07-12 18:00:00+0900", '%Y-%m-%d %T%z');   # print 09:00:00
parse_time("2012-07-12 18:00:00+0300", '%Y-%m-%d %T%z');   # print 15:00:00

日付フォーマットを規定したISO8601では、タイムゾーンの定義はこんな感じ

ISO8601
TZD = time zone designator (Z or +hh:mm or -hh:mm)  

perldocにも書いてありますが、Time::Pieceの時刻フォーマットはFreeBSDコマンドのstrftimeに準拠していて、ISO8601ではなくて、RFC822に依存します。

RFC822

zone        =  "UT"  / "GMT"       ; Universal Time

                                              ; North American : UT

            /  "EST" / "EDT"           ;  Eastern:  - 5/ - 4

            /  "CST" / "CDT"           ;  Central:  - 6/ - 5

            /  "MST" / "MDT"          ;  Mountain: - 7/ - 6

            /  "PST" / "PDT"           ;  Pacific:  - 8/ - 7

            /  1ALPHA                 ; Military: Z = UT;

                                             ;  A:-1; (J not used)

                                             ;  M:-12; N:+1; Y:+12

            / ( ("+" / "-") 4DIGIT )    ; Local differential

                                             ;  hours+min. (HHMM)

ということで、HH:MMな表記はHHMMに直さねばなりません。そして%zで受ける必要があります。ちょと不思議なのは、Time::Pieceでこれが出来ないことです。※7/24追記 下記のDateTime::Format::Strptimeはできる

parse_time("2012-07-12 18:00:00 JST", '%Y-%m-%d %T %Z'); # error!

これは自前で±HHMMに置き換えるしか無いのかなぁ。

なおDateTime::Format::Strptimeでも同じような事ができますが、同じく正しいのは一番下のみ下の２つになります。7/24追記※GMTのケースは%Zの前にスペースが無いだけでした

use strict;
use warnings;
use DateTime::Format::Strptime;

sub parse_time {
    my ($time, $format) = @_;
    my $d = DateTime::Format::Strptime->new(pattern => $format)->parse_datetime($time);
    $d->set_time_zone("UTC");
    warn $d->strftime('%Y-%m-%d %T %Z');
}

parse_time("2012-07-12 18:00:00+09:00", '%Y-%m-%d %T+09:00');
#parse_time("2012-07-12 18:00:00 GMT", '%Y-%m-%d %T%Z'); 7/24訂正
parse_time("2012-07-12 18:00:00 GMT", '%Y-%m-%d %T %Z'); 
parse_time("2012-07-12 18:00:00+0900", '%Y-%m-%d %T%z');

問題を解りづらくしていたのは以下の様なコードの時に

eval { Time::Piece->strptime($str, '%Y-%m-%d %T+09:00') } ||
eval { Time::Piece->strptime($str, '%Y-%m-%dT%T JST') }

2011-07-12 18:00:00+09:00のような日付が渡ってきた場合、パースはできるけど、Time Zoneを考慮しないという点でしょう。ちょっとはまりました。

Windows Vistaがロールアウトしてから、もうすぐ半年。 なかなか企業での導入が進みません。 理由としては

• マルチメディア機能など、企業にとってはどうでも良い
• アプリケーションのサポート状況が固まっていない
• セキュリティが不安
• 文字コードの問題

などなどがあげられます。 本格的に導入が始まるのは、SP1が出たあと（おそらく来年初頭）になるでしょう。 が、我々エンジニアはそうも言っていられません。 ちらほらVista対応なんて言葉が出てくるはずです。 特に意識すべきは文字コードの問題です。 これが結構な大問題。 １．XPとVistaでは文字の見え方が違う ２．一部の文字がサロゲートペア という状態です。 １はいいんですけど、２が大問題です。 まずは１から簡単に説明します。 したのPDFはMicrosoftから出ているグリフの違いに関するドキュメントです。 右がXPで表示したとき、左がVistaです。 これはXPではJIS X 0208、VistaではJIS X 0213という文字コードが使われているからなんですけど、 正しいのはVistaの方です。 JIS X 0213:2004に関する資料は、Microsoftのこのページからダウンロードできます。 JIS X 0208が間違えているんですね。ソレを0213で修正したわけなんですけど、 今企業にあるのはほとんどがXPなわけだし、環境によって見え方が違うのはちょっと気持ち悪いですね。 これはモジコードの問題なので、XP用の0213の文字セットもあるし、 Vista用の0208の文字セットもあるので、このことが説明できれば良いでしょう。 Windows XP および Windows Server 2003 向け JIS2004 対応 MS ゴシック &MS 明朝フォントパッケージ Windows Vista 向け JIS90 互換 MS ゴシック & MS 明朝フォントパッケージ 問題は２です。サロゲートペア。 あ〜もう！って感じです。 何が困るかという話の前にUnicodeについてお話させてください。 1980年代、コンピュータ上で多言語をシームレスに扱えるようにしようという動きがありました。 提唱はゼロックスで、協力した企業として、マイクロソフト、アップル、IBM、サン･マイクロシステムズ、ヒューレット･パッカード、ジャストシステムなどが参加したユニコードコンソーシアムによって策定されました。 今は、ISO/IEC 10646として国際標準になっています（厳密にはUCSのことを定義している）。 で、このUnicode。 16ビットを使って一文字を表現しています。 16ビットで表現できるデータは65,536ですね。 問題は、65536文字で全ての言語の文字を表現できるか？って事です。 むろん出来るわけない。全然足りなくて、空いた２万文字の争奪戦が勃発したぐらいです。 このUnicodeをUnicode1.0といいます。 ではどうするか？というと、 さらに16ビット追加して、32ビットで一文字を表現する領域を作ったわけです。 無論今までの16ビットで表現できる文字はそのままです。 と言う事は、Unicode2.0には、16ビットで一文字をあらわすものと、32ビットで一文字をあらわすものが混在する、可変長な文字セットになっています。 この32ビットであらわす方法をサロゲートペアって言います。 可変長な文字扱うのって大変なんですよぉ・・ヽ(´Д`；)ﾉｱｩｱ... そんなの関係あるの？と思った方。 それが大アリなのですよ！ 例えばC#でcharに文字を代入するばあい、 char hoge = '[非サロゲートペア文字]' はOKですが、 char hoge = '[サロゲートペア文字]' はコンパイルエラーになります。 なぜか？というと・・・charが16ビットまでだからですねぇ。 じゃあ、どうするのか？ String piyo = "[サロゲートペア文字]" こうするしかないのです。 もーね、コレが同いう事を意味するかプログラマならわかると思うのですが、piyo.lengthとか当てにならないわけですよ。 ほんと、「あ〜ぁ」って感じ(*´д`) 我らが愛する正規表現も影響を受けます。 バイト単位で見るため非サロゲートペア2文字 = サロゲートペア一文字でマッチしてしまう可能性は、大いにあります。回避策はちゃんとあるんですけどね。 プログラミングだけじゃないです。 インフラストラクチャレベルも影響を受けます例えば、RDB。 データ格納するだけならいいんですが、検索やキーに指定した場合は同様に問題が起こります。 アプリの実装に関しては、JIS X 0213:2004 / Unicode 実装ガイドが役に立ちそうです。

Powered by ScribeFire.

おなじみscriptaculous.jsでスライダーインターフェースを実現するControl.Slider。 すっごく便利なんだけど、なぜか1pxしかスライドしないバグで1日はまってしまいました。 どうやら下記のようにスタイルのvisibilityやdisplay非表示にすると駄目らしい。

<div id="slide" style="display: hidden;">
<div id="track1" style="margin: 40px; height: 200px; background-color: rgb(170, 170, 170); width: 1px;">
<div class="selected" id="handle1" style="width: 10px; height: 5px; background-color: rgb(255, 0, 0); position: relative; top: 25px;"></div>
　</div>
</div>

まだ確認が取れていなくて、私の予測でしかないのですが、 おそらく、 new Control.Slider()された時点で、画面上で非表示になっていると、 スライド幅（デフォルトではスライドするトラックのピクセル長）が取得できず、上手く動かないようだ。 オプションのmaximumあたりの指定で回避できるかも知れないけど、 あまり頻繁に遭遇するシュチュエーションではないので、未確認。 取り合えず回避策としては初期表示の際はdisplay: block;にしておいて、 onload()で$('id').style.display=hidden;にすることで回避。 onloadにあまり局所的なコード入れたくないけど、一応応急対処。 オプション辺り試してみて回避可能であれば追記します。 でもこんな使い方するひといるのかな〜？