Notice alert display wrong time

[proyb2]

I have created a new datasource and the green notice message at the top showing "created 6 hours ago" instead of "a few milliseconds ago"?

Based on:
http://symphony-cms.com/discuss/thread/86867/#position-5

Screenshot:
http://postimage.org/image/vfsq53pwl/

Details:
2.3RC1 (Integration)

Installation Timezone set to Singapore

Google Chrome
No error in manifest log
This is reproducible on Sections, Page, etc as well. Could it be related to timezone?

[nilshoerrmann]

Symphony compares the time returned by your server with the time in your browser. Please check if both sides are set up correctly.

[proyb2]

Tested on local PC is indeed 6 hours earler than my Windows system time.

Will there be any issue if the user is located in other timezone where my server is 8am and user is 2am?

[nilshoerrmann]

Hm, there shouldn't be any problems: we compare timestamps and those always refer to GMT as far as I know.

[kanduvisla]

Could be the same issue, since my timezone setting is GMT +0200, but earlier versions of Symphony always showed this right. Is the time showed perhaps calculated with JavaScript, and therefore comparing the local system time with the remote server time?

[brendo]

The handling of time ago has changed, and I tend to agree that's it's a bit of regression.

In 2.2.5, the date in the message was parsed via in Javascript with Date.parse() to return the UNIX timestamp. Two new 'date' objects were created, new Date(), and then one was passed the timestamp with .setTime. This meant that the time suddenly became the same as your computer clock.

I think this is the correct behaviour, while comparing from the server time to the browser time seems 'right', it doesn't really make sense, because the entry was not saved 2 hours ago, but it was saved just then, by you.

[brendo]

This fails on -GMT timezones, such America/Kentucky/Louisville. Reports here and here

[nilshoerrmann]

What about adding an additional data-timestamp attribute to Widget::time(). This way, the JavaScript won't have to convert the given date to a timestamp first (at least I guess this is where the error occurs).

[brendo]

That sounds like a good solution