Robomongo: Options - Display Dates in - Local Timezone shows wrong date.

[adamjmendoza]

Options - Display Dates in - Local Timezone shows wrong date.

Displaying dates in local time zone added + 17 instead of - 7 for my timezone.

Robomongo version 0.8.4 on Windows 8.1 64bit.

[stennie]

The date feature seems to work as expected for me using Robomongo 0.8.4 on OS X. I haven't tested in Windows yet so it is possible there is an O/S-specific bug.

For example, I tried:

    datenow = new Date();
    db.foo.insert({date: datenow});
    db.foo.find({date:datenow})

I suspect the problem may be that the dates you have saved in MongoDB have a different timezone offset than you are expecting. Can you try the above example and see if that works for you?

Thanks!

[stennie]

Seems OK in Robomongo 0.8.4 on Windows as well.

Please feel free to reopen with additional details if you are able to reproduce the problem.

Thanks!

[pepkin88]

@stennie I also encountered this bug. I'm using Robomongo 0.8.4 for Windows and my current timezone is CEST (+02:00).
When I'm using Robomongo from 2:00 to 23:59 the date is shown properly (2014-07-18T01:05:28.718+02:00), but from 0:00 to 1:59 I get -22:00 timezone offset (2014-07-17T01:05:28.718-22:00). As you can see time is shown properly, but date is a day earlier. It doesn't matter what is the value of the date field, but when it is retrieved by Robomongo. It is also dependent on the local machine time, rather than MongoDB server time.
I hope it'll help to reproduce this bug.

[stennie]

@pepkin88 Can you include an example of the MongoDB query output with dates in UTC format vs converted to local timezone? As I commented earlier, my suspicion was that some of the dates were not saved with the expected timezone offset .. but your comment suggests something more subtle based on current local time.

Can you also confirm your versions of Windows + MongoDB? May not be relevant for this issue, but would like to be sure in case this helps reproduce the problem.

Thanks!

[pepkin88]

@stennie Windows 7 x64 Professional. MongoDB 2.6.3, runs on Ubuntu 14.04 Linux server.
Output in UTC:

/* 0 */
{
    "_id" : ObjectId("53c856b8b0aa31b75407120c"),
    "timestamp" : ISODate("2014-07-17T23:05:28.718Z")
}

Output in local format (good):

/* 0 */
{
    "_id" : ObjectId("53c856b8b0aa31b75407120c"),
    "timestamp" : ISODate("2014-07-18T01:05:28.718+02:00")
}

Output in local format (after I changed my computer's time to 1:38) (bad):

/* 0 */
{
    "_id" : ObjectId("53c856b8b0aa31b75407120c"),
    "timestamp" : ISODate("2014-07-17T01:05:28.718-22:00")
}

[stennie]

@pepkin88 Thanks for the extra info .. will have look at the date conversion code.

[hluz]

I can see this also:
On Mac OS X, Melbourne, Australia timezone
Stored date (display dates in UTC): ISODate("2014-10-16T08:05:00.001-13:00")
When (display dates in local time zone: ISODate("2014-10-16T21:05:00.001Z")

Melbourne time zone is not Z -13:00 but Z +10:00...

Strange thing is that a few weeks back (I suspect before daylight savings adjustment in first weekend of this month) it was displaying correct local time dates...

[hluz]

Update: It is displaying correctly again. There was a change on GMT timezone to no daylight saving last weekend, and that appeared to fix it. In summary, it displayed incorrectly for the few weeks between Melbourne went Daylight Savings and before GMT exited Daylight Savings...

[BradRuderman]

I am not sure when it is starting but it is now displaying incorrectly. I store the date in the server as UTC. My local client is set on Pacific time.
Here is the info

Server:

"DateCreated" : ISODate("2015-02-28T19:06:42.000Z")

Shown

"DateCreated" : ISODate("2015-03-01T11:06:42.000+16:00"),

Computer is in the Mac OS X Latest Yosemite 10.10.2, set to Pacific Standard Time, syncing with Apple server. The correct time should covert to:

"DateCreated" : ISODate("2015-02-28T11:06:42.000-08:00"),

[SadBunny]

We can reproduce this problem on two different Windows 7 machines running Robomongo 0.8.4. Upgraded one to 0.8.5, still the same problem. (We have not tested on any other machines.)

We're in Sydney, timezone AEST, which is currently at UTC (Zulu) +1100. Looking at the exact same record, between midnight (00:00) and 10:59 (am) we get:

"DateTime" : ISODate("2015-03-16T11:00:00.000-13:00"),

... and between 11:00 (am) and 23:59 (pm), we get

"DateTime" : ISODate("2015-03-17T11:00:00.000+11:00"),

for the exact same record. Which in zulu mode always (not dependant on time of day) gives:

"DateTime" : ISODate("2015-03-17T00:00:00.000Z"),

(The timestamp itself is always correct: it is intented to represent UTC midnight and it does. Robomongo just seems to get the timezone offset wrong, i.e. off-by-24-hours, but calculates the resulting timestanp correctly based on that wrong offset.)

[stennie]

@SadBunny Thanks for the more specific info. I'm in Sydney as well fwiw ;)

[SadBunny]

@stennie So... Any ideas on how we can fix this? Or is just a bug in the Robomongo code that can be fixed? If you need any more tests, I'd be happy to oblige.

[stennie]

@SadBunny Assume it's just a bug in the code .. needs bandwidth for someone to look into it. My priority at the moment is getting the MongoDB 3.0 shell integrated for the Robomongo 0.9.0 milestone ;-).

[SadBunny]

@stennie Thanks, then I won't be looking at something in our environment causing it. (Which was possible, because apparently this cannot be reproduced everywhere, judging from earlier posts in this thread.) It's only a visual issue.

[pwae]

Just re-iterating @SadBunny 's points. Same data, but using OS X (0.8.4), and having the same issue as well.

[dsernst]

Happening here: the local timezone option is displaying dates as +16:00, but my computer is set to -8:00.

OS X 10.11.2, Robomongo 0.8.5

[KuttKatrea]

I've detected this bug again in 0.9.0-RC10

[simsekgokhan]

Hi All,

There are some fixes related to timezone and date type on latest release Robomongo 1.0.
I hope it will solve some of your problems:
https://robomongo.org/download
http://blog.robomongo.org/robomongo-1-0/ -> section "c. Bug fixes"