コード内で「現時刻」を気軽に取得してはいけない | Nekoya press
日付を扱う処理についていろいろまとめたついでに、わりと簡単なことだけど知らないと落とし穴にハマる系のネタを。 日頃いろいろな処理を書いていて、現時刻を扱うこともは少なくないはずです。ですが、これを適当にやっていると困ることが多々あります。 実行中に「現時刻」を元にした処理が食い違う 例えばこんなコード。ログ集計とかやってるイメージです。 class Analyzer(object): def analyze(self): logfile = datetime.datetime.now().strftime('my_log_file.%H') self.save(self.analyze_logfile(logfile)) def save(self, result): now = datetime.datetime.now() self.result[now.hour] = result
MySQL-python1.2.4でdatetimeから文字列の変換方法が変わった件 | Nekoya press
MySQL-python（MySQLdb）を上げたら、今まで通ってたテストでwarningが出るようになりました。 MySQLdb/times.pyで以前は def format_TIMESTAMP(d): return d.strftime("%Y-%m-%d %H:%M:%S") こうなっていたものが、 def format_TIMESTAMP(d): return d.isoformat(" ") こうなったのが原因らしいのだけど、Changelogを見てもそれらしい表記がないので少し経緯を追ってみました。 この変更で何が問題になったかというと、 >> import datetime, pytz >>> datetime.datetime.now(pytz.utc).isoformat(' ') # aware '2013-06-27 01:50:16.156481+00:00' >
Pythonのdatetimeで夏時間を扱う | Nekoya press
「Pythonの日付処理とTimeZone」を書いた後、Twitterで指摘をもらっていたのを遅ればせながら検証したので、改めてエントリを起こしてみました。 Pythonの日付処理とTimeZone http://t.co/KK1B5Fot0V datetime を tzinfo 付きで生成する場合は pytz.tzinfo.normalize しないと DST 境界を超えるところで存在しない時刻を作りますよ — Jun Omae⁽⁶⁶ʲ⁵⁾ (@jun66j5) June 22, 2013 @jun66j5さんありがとうございました。 このへんの背景はpytzのサイトにありますが、そもそもサマータイムに馴染みがないのでどうあるべきかがしっくりきません。 標準時と夏時間の切り替わり ここでは、ニューヨークが属するTimeZoneを例に話を進めます。まずは基本的な用語の整理から。 DST …
Pythonの日付処理とTimeZone | Nekoya press
日付周りの処理というのはとても難しい問題で、特にTimeZoneが絡むと基本的に大変なことになります。 Pythonは標準で用意されているdatetimeモジュールが高機能なので、それを使っておけば間違いない感があって、そういう意味では安心感があります。 とは言え、その扱いにはやはり注意が必要で、現時点でこうするのがいいかなーと思っていることをつらつらと記録したエントリがこちらです。 基本的にはMacのPython2.7.1で検証して、おやっと思ったところはCentOS5.8のPython2.6.5やUbuntu12.04のPython2.7.3で追試しています。 なお、datetime.datetimeと書くのがだるいので本文中では、 from datetime import datetime を前提としています。 naiveとaware 公式ドキュメントにそのまま載ってるけど、date
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
