View Issue Details

IDProjectCategoryView StatusLast Update
0005069Talermechant backendpublic2017-10-18 15:42
ReporterChristian Grothoff Assigned ToMarcello Stanisci  
Status closedResolutionfixed 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product Versiongit (master) 
Target Version0.4Fixed in Version0.4 
Summary0005069: date is in wrong timezone in backoffice list
DescriptionShows in "london"? time. We should _store_ in UTC in Database, but show in localtime (of the server).
TagsNo tags attached.


Marcello Stanisci

2017-06-27 14:51

viewer   ~0012273

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?

Christian Grothoff

2017-06-29 12:36

manager   ~0012279


Marcello Stanisci

2017-07-07 11:23

viewer   ~0012306

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.

Christian Grothoff

2017-07-07 14:31

manager   ~0012307

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"?

Marcello Stanisci

2017-07-07 14:49

viewer   ~0012308

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.

Christian Grothoff

2017-07-07 14:52

manager   ~0012309

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.)

Marcello Stanisci

2017-07-07 14:59

viewer   ~0012310

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.

Florian Dold

2017-07-07 15:18

manager   ~0012311

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

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).

Marcello Stanisci

2017-07-07 15:31

viewer   ~0012312

+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)?

Marcello Stanisci

2017-07-07 15:32

viewer   ~0012313

we load new results from /history API of course

Florian Dold

2017-07-07 15:33

manager   ~0012314

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).

Marcello Stanisci

2017-07-07 15:35

viewer   ~0012315

Yeah, as I wrote above, timestamps come from backend's /history API, included in JSON data.

Christian Grothoff

2017-07-07 16:12

manager   ~0012316

I'm ok with JS client-side converting to local time.

Marcello Stanisci

2017-07-07 22:37

viewer   ~0012317

Solved in 2bfc844.

Issue History

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