Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the MongoDB CPAN distribution.

Maintainer(s)' notes

Please don't report bugs here. Please use the MongoDB Perl driver issue tracker instead.

Report information
The Basics
Id: 57004
Status: rejected
Priority: 0/
Queue: MongoDB

People
Owner: Nobody in particular
Requestors: whatson [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Time zone of DateTime objects is ignored upon retrieval
Date: Wed, 28 Apr 2010 17:18:43 +1000
To: bug-MongoDB [...] rt.cpan.org
From: Andrew Whatson <whatson [...] gmail.com>
Hi, MongoDB appears to be ignoring the time zone of stored DateTime objects upon retrieval. I have attached a patch to add a failing test to MongoDB-0.33 which demonstrates this issue. Analysis of the data in the database shows that the time zone is stored correctly, so the bug must lie in the code that creates a DateTime object from the stored value. Looking at the code that decodes the retrieved data, it seems you need to specify the 'time_zone' parameter along with 'epoch' to the 'from_epoch' method of DateTime. Regards, Andrew

Message body is not shown because sender requested not to inline it.

As we discussed on IRC, the database does not store timezones, it just stores milliseconds since epoch. I think the driver is doing the right thing, as it converts dates to UTC and retrieves them as UTC. If you convert the date to the correct time zone, you get back the original date you had. So, if you do: my $dt_in = DateTime->now; $dt_in->set_time_zone('Australia/Brisbane'); $c->insert({'date' => $dt_in}); my $out = $c->find_one; my $dt_out = $out->{'date'}; $dt_out->set_time_zone('Australia/Brisbane'); $dt_in and $dt_out will be the same date. You'll have to save the timezone as another field in the document if you need to keep track of it.