Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

samtregar (2699)

samtregar
  (email not shown publicly)
http://sam.tregar.com/

Journal of samtregar (2699)

Tuesday April 04, 2006
06:18 PM

DateTime->now() versus localtime()

[ #29218 ]
What's wrong with this picture:

   $ perl -MDateTime -e 'print DateTime->now()'
   2006-04-04T23:08:37

   $ perl -e 'print scalar localtime'
   Tue Apr  4 19:09:10 2006

It seems that DateTime->now() doesn't do what I thought it did. I thought it returned the current date and time at this point on the planet. What it actually does is return the current date and time in UTC! (And please don't tell me that DateTime can't reliably figure out my timezone. Perl's localtime() manages just fine!) (You can, however, lambaste me for not reading the DateTime docs, since it's quite clear that now() doesn't return local time.)

Unfortunately I discovered this only in the late stages of testing version 3 of a large application that makes moderately extensive use of Datetime. That means the "easy" way to fix this, namely:

    $ perl -MDateTime -e 'print DateTime->now(time_zone => "local")'
    2006-04-04T19:12:03

Isn't so easy, as it would mean touching a lot of files.

As far as I can tell I don't have a lot of good options here. I'm going to make a sub-class of DateTime which defaults to "local" for now(), new() and from_epoch(), but that will still mean touching lots of files. I did find discussion of this problem on the DateTime lists, but I don't think a solution made it into the module.

I did discover that Tim Bunce considers my chosen solution "trivial", whatever that means!

-sam


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

DateTime->now() versus localtime() 15 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • > I discovered this only in the late stages of testing version 3 of a large application that makes moderately extensive use of Datetime.

    How is this possible? How can you have been using versions 1 and 2, and well into testing version, with the time stamps off by hours, without anyone noticing?

    • Hard to say for sure. I think the biggest factor is that although we do lots of date math in the application the actual times don't matter very much to the client. They'd tell us within a few days if we ever got the dollar amounts wrong but noticing a shift of a few hours on a monthly or weekly report is pretty tough.

      Another factor is that a lot of the most important dates were right. MySQL has a DWIM that matched our expectations - NOW() really is now, right here, on this spot on the planet. So times

  • 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.

    • 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

        • You could also note that it displays the date by default in ISO8601 format, which has the fields in an order that most humans don't use in their day-to-day lives.

          I do, now, ever since I first used DateTime and thought, "What is that weird format, and why do they use it?"

          --
          J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • If you want a solution without touching many files, consider redefining DateTime::now. After using DateTime, rename its now subroutine to something else (say __now), and install something like:
      sub DateTime::now {
          push @_ => time_zone => "local";
          goto &DateTime::__now;
      }

  • I simply switched my own personal timezone to UTC. My watch is set to UTC, my PC timezone is set to UTC, my TZ variables everywhere I go are set to UTC, my Wikipedia preferences are set to UTC, my forum preferences many places on the net are set to UTC. I know when the sun rises and sets. I'm always reminded to convert timestamps for the benefit of my coworkers, 100% of whom are all distributed across the other three continental U.S. timezones. The hardest part is twice a year when I have to remember th

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • What is this 'MySQL' of which you speak? :-)

    I hate date time conversions in general. They're right up there is characher/codepage conversions in my book if things no human should ever have to think about.

    In MSSQL land, we have GETDATE(), and GETUTCDATE(). Converting them on the fly is even more fun.
  • Using DateTime.pm instead of Time::Piece. You would have just got the right thing using localtime vs gmtime that way.
  • Time.now # localtime
    Time.now.utc # UTC

    Why not make DateTime->now() return localtime and create a utc() method? I guess it would break backwards compatibility, though.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.