wui: show time page was rendered #1972

New Issue

leif · 2013-05-19T06:16:04Z

leif commented

2013-05-19 06:16:04 +00:00

While troubleshooting something, I found myself with several open browser tabs showing my gateway in different states and realized that I did not know which view was rendered when.

It would be useful to include a timestamp at the bottom of the page (alongside the verbose version information already present).

While troubleshooting something, I found myself with several open browser tabs showing my gateway in different states and realized that I did not know which view was rendered when. It would be useful to include a timestamp at the bottom of the page (alongside the verbose version information already present).

leif added the

labels 2013-05-19 06:16:04 +00:00

leif added this to the undecided milestone 2013-05-19 06:16:04 +00:00

leif commented

2013-05-19 06:32:14 +00:00

When there is at least one disconnected server, the page render time is currently displayed in the "since" column. (#1973)

leif commented

2013-05-19 07:47:18 +00:00

Submitted pull request: https://github.com/tahoe-lafs/tahoe-lafs/pull/42

Submitted pull request: <https://github.com/tahoe-lafs/tahoe-lafs/pull/42>

daira commented

2013-05-19 22:05:17 +00:00

Reviewing.

tahoe-lafs added

code-frontend-web

and removed

unknown

labels 2013-05-19 22:05:17 +00:00

tahoe-lafs modified the milestone from undecided to 1.11.0

2013-05-19 22:05:17 +00:00

Daira Hopwood <david-sarah@jacaranda.org> commented

2013-05-19 22:33:59 +00:00

In /tahoe-lafs/trac-2024-07-25/commit/ec191bfca6e1cd3d31b4f206c56304caa69c82cf:

WUI: add time page was rendered to client and introducer welcome pages. closes #1972

Author: Leif Ryge <leif@synthesize.us>
Signed-off-by: Daira Hopwood <david-sarah@jacaranda.org>

In [/tahoe-lafs/trac-2024-07-25/commit/ec191bfca6e1cd3d31b4f206c56304caa69c82cf](/tahoe-lafs/trac-2024-07-25/commit/ec191bfca6e1cd3d31b4f206c56304caa69c82cf): ``` WUI: add time page was rendered to client and introducer welcome pages. closes #1972 Author: Leif Ryge <leif@synthesize.us> Signed-off-by: Daira Hopwood <david-sarah@jacaranda.org> ```

tahoe-lafs added the

fixed

label 2013-05-19 22:33:59 +00:00

Daira Hopwood <david-sarah@jacaranda.org> closed this issue

2013-05-19 22:33:59 +00:00

daira commented

2013-05-19 22:36:02 +00:00

I added some tests and changed the time format to be consistent with the 'Announced' and 'Since' columns.

zooko commented

2013-05-22 23:43:00 +00:00

Per #1077 timestamps should be generated by a call to [time_format.py]source:trunk/src/allmydata/util/time_format.py?annotate=blame&rev=7607268a58f31842f94c415a3403c6740c898679.

daira commented

2013-05-23 03:32:49 +00:00

iso_utc and iso_local in time_format.py output time to nanosecond resolution, which is false precision and not appropriate for this use. Also iso_local doesn't include an RFC 3339 timezone offset.

`iso_utc` and `iso_local` in `time_format.py` output time to nanosecond resolution, which is false precision and not appropriate for this use. Also `iso_local` doesn't include an [RFC 3339 timezone offset](https://tools.ietf.org/html/rfc3339#section-4.2).

zooko commented

2013-05-23 05:26:35 +00:00

Replying to daira:

iso_utc and iso_local in time_format.py output time to nanosecond resolution, which is false precision and not appropriate for this use. Also iso_local doesn't include an RFC 3339 timezone offset.

How about making those issues separate tickets?

Replying to [daira](/tahoe-lafs/trac-2024-07-25/issues/1972#issuecomment-91769): > `iso_utc` and `iso_local` in `time_format.py` output time to nanosecond resolution, which is false precision and not appropriate for this use. Also `iso_local` doesn't include an [RFC 3339 timezone offset](https://tools.ietf.org/html/rfc3339#section-4.2). How about making those issues separate tickets?

daira commented

2013-05-25 01:07:31 +00:00

Replying to [zooko]comment:8:

Replying to daira:

iso_utc and iso_local in time_format.py output time to nanosecond resolution, which is false precision and not appropriate for this use. Also iso_local doesn't include an RFC 3339 timezone offset.

How about making those issues separate tickets?

Why would we change the timestamp to a more ugly format only so that we have to fix it again? Let's change iso_utc and iso_local first.

Replying to [zooko]comment:8: > Replying to [daira](/tahoe-lafs/trac-2024-07-25/issues/1972#issuecomment-91769): > > `iso_utc` and `iso_local` in `time_format.py` output time to nanosecond resolution, which is false precision and not appropriate for this use. Also `iso_local` doesn't include an [RFC 3339 timezone offset](https://tools.ietf.org/html/rfc3339#section-4.2). > > How about making those issues separate tickets? Why would we change the timestamp to a more ugly format only so that we have to fix it again? Let's change `iso_utc` and `iso_local` first.

zooko commented

2013-05-25 01:10:24 +00:00

This ticket should be rewritten to: "Make all timestamps be generated by the same code, and be in a consistent format with one another.".

zooko commented

2013-05-25 01:11:03 +00:00

Replying to zooko:

This ticket should be rewritten to: "Make all timestamps be generated by the same code, and be in a consistent format with one another.".

Sorry, I mean that ticket -- #1077.

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/1972#issuecomment-91772): > This ticket should be rewritten to: "Make all timestamps be generated by the same code, and be in a consistent format with one another.". Sorry, I mean *that* ticket -- #1077.

Sign in to join this conversation.