View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005069 | Taler | mechant backend | public | 2017-06-06 13:45 | 2017-10-18 15:42 |
| Reporter | Christian Grothoff | Assigned To | Marcello Stanisci | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 0.4 | Fixed in Version | 0.4 | ||
| Summary | 0005069: date is in wrong timezone in backoffice list | ||||
| Description | Shows in "london"? time. We should _store_ in UTC in Database, but show in localtime (of the server). | ||||
| Tags | No tags attached. | ||||
|
|
The blog shop is such that the merchant backend sets the time of a contract, using GNUNET_TIME_get_current(), which in turn uses gettimeofday(). Documentation is a bit vague on that, so I ask you: are GNUnet generated timestamps already UTC? |
|
|
Yes. |
|
|
JS Date() object doesn't have a "toSOMETIMEZONEString()" method that converts UTC time to pretty string representation of time in SOMETIMEZONE. According to some Googling, there are libraries that do that, but we want to avoid those as much as possible. However, JS Date() too keeps time in UTC internally; and fortunately it can pretty print time in UTC. The solution here can be to "trick" the Date() object by initializing it with a faked up timestamp that respects the server timezone. Basically, backend's /history response will have a "time_offset" field which is the following object: { "sign": "+/-" "offset": xy } such that the server timezone timestamp is "UTC sign offset". So the backoffice JS will do this simple math and initialize the various Date() objects with the obtained timestamp; finally it will pretty print the time with a "toUTCstring()" method that will actually print the time in the server timezone. |
|
|
I'm a bit confused. I thought you were using JS to do the conversion client-side to get the client's TZ. Since when do we have JS on the server-side? Did you mean to end "in the client timezone"? |
|
|
No JS on the server-side. You asked (see issue description above) to print times in local time of the *server*; so I actually meant "server timezone". So it's me to be confused now. |
|
|
Yes, that's what I did suggest, but then I totally don't get why you want to use client-side JS. Client-side JS would make sense to convert to client-timezone, but for server-timezone I don't get it at all. (And obviously the choice between server-timezone and client-timezone is debatable.) |
|
|
I want to work times in JS because history elements have timestamps, and I didn't want to touch them -- basically I wanted those to keep matching contracts (official/legal) timestamps. |
|
|
I really don't see a reason in the first place why we would want to display the dates in the server's timezone, that's just gonna cause confusion and make things even more complicated. IMHO the best solution here is "progressive enhancement": on the server you render the date in UTC, and the client can run JavaScript to convert it to the local time zone. So every date would look like this in HTML: <span class="timestamp" data-timestamp="1499431252411"> Fri, 07 Jul 2017 12:40:52 GMT </span> And unless NoScript is active, the dates will be converted to the user's timezone. Alternatively that server can already determine the user's timezone, but that's rather messy, since HTTP does not have affordances for this. So either we'd need to do manual selection (bad!) or use JavaScript to infer the user's date and then set a cookie on the server (also rather clunky). |
|
|
+1 to display dates in client's timezone. As for what you suggest: who does the HTML rendering of the date? Frontend or client-side JS? Would it be OK with the scrolling effect we have (remember we load new results upon reaching the bottom of the page)? |
|
|
we load new results from /history API of course |
|
|
If the timestamp is part of the page, then it should be rendered like I wrote above. If we get the timestamp as part of some JS API, then we need to render it via JS anyway. For this, "Date" supports everything we need (UTC timestamp to local date/time). |
|
|
Yeah, as I wrote above, timestamps come from backend's /history API, included in JSON data. |
|
|
I'm ok with JS client-side converting to local time. |
|
|
Solved in 2bfc844. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-06-06 13:45 | Christian Grothoff | New Issue | |
| 2017-06-06 13:45 | Christian Grothoff | Status | new => assigned |
| 2017-06-06 13:45 | Christian Grothoff | Assigned To | => Marcello Stanisci |
| 2017-06-27 14:51 | Marcello Stanisci | Note Added: 0012273 | |
| 2017-06-29 12:36 | Christian Grothoff | Note Added: 0012279 | |
| 2017-07-07 11:23 | Marcello Stanisci | Note Added: 0012306 | |
| 2017-07-07 14:31 | Christian Grothoff | Note Added: 0012307 | |
| 2017-07-07 14:49 | Marcello Stanisci | Note Added: 0012308 | |
| 2017-07-07 14:52 | Christian Grothoff | Note Added: 0012309 | |
| 2017-07-07 14:59 | Marcello Stanisci | Note Added: 0012310 | |
| 2017-07-07 15:18 | Florian Dold | Note Added: 0012311 | |
| 2017-07-07 15:31 | Marcello Stanisci | Note Added: 0012312 | |
| 2017-07-07 15:32 | Marcello Stanisci | Note Added: 0012313 | |
| 2017-07-07 15:33 | Florian Dold | Note Added: 0012314 | |
| 2017-07-07 15:35 | Marcello Stanisci | Note Added: 0012315 | |
| 2017-07-07 16:12 | Christian Grothoff | Note Added: 0012316 | |
| 2017-07-07 22:37 | Marcello Stanisci | Status | assigned => resolved |
| 2017-07-07 22:37 | Marcello Stanisci | Resolution | open => fixed |
| 2017-07-07 22:37 | Marcello Stanisci | Note Added: 0012317 | |
| 2017-10-11 14:13 | Christian Grothoff | Fixed in Version | => 0.4 |
| 2017-10-18 15:42 | Christian Grothoff | Status | resolved => closed |
