search

thesentinelproject / threatwiki_node

Threatwiki - genocide risk tracking and visualization platform to help monitor communities at risk of genocide around the world
Other
63 stars 25 forks source link

Before saving dates, normalize timezone #16

Closed ghost closed 12 years ago

jeromegv commented 12 years ago

will work on that

abhishekbh commented 12 years ago

I was playing around with a related lib and saw the fix, so I ended up committing.

jeromegv commented 12 years ago

Hmm I think there was misunderstanding of how to fix that issue. It wasn't about putting the Eastern time in the database. Best practice with time is to save in the database in UTC, but then display in the UI in Eastern time. That way you can have later a UI element that allow you to change timezone displayed to the user, but always keeping the UTC time as ultimate reference.

ghost commented 12 years ago

Ah okay, that's cool. We only have to change all the "America/Toronto"s to UTC then.

The issue was required because the date objects are being generated on the client side, meaning that it is local browser execution. Hence the time generated would always be dependent on the user's time zone, and hence we need to manually force a time zone. Which time zone is a small issue.

Or were you thinking of another way of saving time?

Abhishek Bhatnagar

On Mon, Jun 4, 2012 at 9:54 PM, jeromegv < reply@reply.github.com

wrote:

Hmm I think there was misunderstanding of how to fix that issue. It wasn't about putting the Eastern time in the database. Best practice with time is to save in the database in UTC, but then display in the UI in Eastern time. That way you can have later a UI element that allow you to change timezone displayed to the user, but always keeping the UTC time as ultimate reference.

Reply to this email directly or view it on GitHub:

https://github.com/thesentinelproject/threatwiki_node/issues/16#issuecomment-6116009

jeromegv commented 12 years ago

Really? It was saving in UTC on here, even thought all my system is on EST. Weird weird

On Mon, Jun 4, 2012 at 10:00 PM, thesentinelproject < reply@reply.github.com

wrote:

Ah okay, that's cool. We only have to change all the "America/Toronto"s to UTC then.

The issue was required because the date objects are being generated on the client side, meaning that it is local browser execution. Hence the time generated would always be dependent on the user's time zone, and hence we need to manually force a time zone. Which time zone is a small issue.

Or were you thinking of another way of saving time?

Abhishek Bhatnagar

On Mon, Jun 4, 2012 at 9:54 PM, jeromegv < reply@reply.github.com

wrote:

Hmm I think there was misunderstanding of how to fix that issue. It wasn't about putting the Eastern time in the database. Best practice with time is to save in the database in UTC, but then display in the UI in Eastern time. That way you can have later a UI element that allow you to change timezone displayed to the user, but always keeping the UTC time as ultimate reference.

Reply to this email directly or view it on GitHub:

https://github.com/thesentinelproject/threatwiki_node/issues/16#issuecomment-6116009

Reply to this email directly or view it on GitHub:

https://github.com/thesentinelproject/threatwiki_node/issues/16#issuecomment-6116070

Jérôme Gagnon-Voyer | Technology Analyst jerome@thesentinelproject.org | Skype: jeromegagnonvoyer

abhishekbh commented 12 years ago

Oh huh, well the browser is the parser so the browser must beer doing the normalizing. If you just alert date.now on your browser, do you see utc?

I'll do some research, and unless it turns out that turning to UTC is a standard, we should leave this in. Otherwise it it goes.

Abhishek On Jun 4, 2012 10:03 PM, "jeromegv" < reply@reply.github.com> wrote:

Really? It was saving in UTC on here, even thought all my system is on EST. Weird weird

On Mon, Jun 4, 2012 at 10:00 PM, thesentinelproject < reply@reply.github.com

wrote:

Ah okay, that's cool. We only have to change all the "America/Toronto"s to UTC then.

The issue was required because the date objects are being generated on the client side, meaning that it is local browser execution. Hence the time generated would always be dependent on the user's time zone, and hence we need to manually force a time zone. Which time zone is a small issue.

Or were you thinking of another way of saving time?

Abhishek Bhatnagar

On Mon, Jun 4, 2012 at 9:54 PM, jeromegv < reply@reply.github.com

wrote:

Hmm I think there was misunderstanding of how to fix that issue. It wasn't about putting the Eastern time in the database. Best practice with time is to save in the database in UTC, but then display in the UI in Eastern time. That way you can have later a UI element that allow you to change timezone displayed to the user, but always keeping the UTC time as ultimate reference.

Reply to this email directly or view it on GitHub:

https://github.com/thesentinelproject/threatwiki_node/issues/16#issuecomment-6116009

Reply to this email directly or view it on GitHub:

https://github.com/thesentinelproject/threatwiki_node/issues/16#issuecomment-6116070

Jérôme Gagnon-Voyer | Technology Analyst jerome@thesentinelproject.org | Skype: jeromegagnonvoyer

Reply to this email directly or view it on GitHub:

https://github.com/thesentinelproject/threatwiki_node/issues/16#issuecomment-6116096