All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

Suppose that DateTime were the other way round, and defaulted to the local timezone. Then somebody could've made an equivalent blog post to yours but comparing DateTime->now with gmtime and complaining that they are different!

There are 2 different possible behaviours. Obviously the module can only do 1 of them by default.

I've been inconvenienced the other way round, when I discovered that our MySQL database was storing timestamps in local time rather than UTC — and not storing the timezone. So this means that in autumn when the clocks go back we have 1 hour's worth of recorded times that actually represent 2 hours' data, and no way of distinguishing them.

You're striking at the heart of the matter by bringing up MySQL. That's our DB and it's probably the first place I ever saw a "NOW()" function. As you mention NOW() in MySQL is just like "now" in real life - it's local time. So when I see DateTime->now(), well, I expect the same. And if I called you up right now and said "hey, what time is it now?" you'd probably meet my expectations too!

Sure, that doesn't mean that everyone should expect that or that the developers of DateTime are morons. They ju

Information on the local time may be easy to find everywhere, but the info on the timezone may be much harder. You can get the time difference between localtime and UTC, but that does not uniquely define a timezone.

E.g., in your example, the only thing we know about your timezone is that it is '+0400' now, but we don't know what DST rules you have. So instead of guessing the correct timezone, DateTime chooses to let the user decide.

As you mention NOW() in MySQL is just like "now" in real life - it's local time.

Except that it isn't it's more like floating time, because it doesn't also note the timezone. That's just wrong, because it means that MySQL's timestamps don't map to a particular moment in time, but to several possible moments. And even if you know the physical location, because of daylight-saving time that isn't good enough.

I don't mind at all which timezone MySQL uses to display its times. And I certainly don't