Dates timezone should be explicit

[evilaliv3]

Right now timezone is not rightly handled by the application and the user can bee fooled in quite all the interfaces in knowing a wrong date for the creation, expiration and other information related to submissions and expiration.

This is due to the fact that the timezone is not shown as an explicit information in the dates shown on the platform.

In addition right now some of the dates sent through the email make use of aconfigurable but not know timezone that most of the users do not set and that by default has the Rome value; this in addition to the fact the timezone used (Rome by default) is not know.

This ticket is to keep track of the activities for:

• showing explicitly the timezone in the dates (e.g. 24-07-2016 10:38 +0200)
• rely on the angular functionality that aligns the date to the browser timezone instead of making it configurable by the user; this is the normal behavior of any web app.

[evilaliv3]

Angular is naturally able to detect and use the timezone of the brower: https://docs.angularjs.org/api/ng/filter/date

for this it is simply needed to add the Z element to the date filter; this way starting from a UTC date we will naturally show the date in the user timezone and it will print 4 digit (+sign) representation of the timezone offset (-1200-+1200) like 24-07-2016 10:38 +0200

[evilaliv3]

@NSkelsey would you please review this commit?

[NSkelsey]

@evilaliv3 I really dislike appending +0XXX to every date time.

Additionally, using this for Dates doesn't make any sense. 17-20-16 +0100 is not a good way to represent the day something happened.

There are alternatives:

1. Go back to using local without TZ strings and place an indicator somewhere to tell you the TZ
2. Attach the actual TZ to the date and display EST, CEST, PST etc etc (nobody or their mother thinks in UTC)

[evilaliv3]

nice edit and good suggestions; i was already keeping into account the first.

i totally agree with you but my commit tries first to be explicit and making things homogeneous then we can discuss of this improvements that requires various custom logic for:

1. reading the timezone (angularjs does not export an API for it but us it internally
2. do and the eventuall mapping you are describing (EST, CEST) that is not a short term fix like the one i implemented.

[NSkelsey]

@evilaliv3 @fpietrosanti

Implementing the TZ as an administrator setting that gets set application wide. This is the TZ of the server. The default will be UTC.

Definitely not going to use the +0XXX extensions. IMO It is better to keep the UI minimal and let it be implicit.

If you don't want to reveal the machines TZ, don't change the default. EZ peasy.

Commits incoming.

[evilaliv3]

@NSkelsey: could you please clarify better your idea?

if i'm not wrong you want to simplify to have only a single global setting for the timezone of all the dates shown by the platform (if this is the case let's also change the name to 'timezone' instead of 'default_timezone')

i'm not against this semplification given the usage that has been done;

in my experience i also feel that this simplification could be done because i've never seen a single user requiring this. what i suggest is to leave as possibility for the recipient to configure a custom timezonee and make the option subject to an enabler like:

• use a custom timezone: true/false
• timezone: dropdown

this is in fact relevant for initiatives where the node has a main timezone but some recipients are on the other side of the world.

as a separate point i think that the timezone should be communicated explicilty in a way or an other (can be always there or visible with a popover) but users should be aware precisely of this.

[evilaliv3]

ah i forgot to write an important aspect: sadly my idea of having and automatic detection of the timezone does not work on the Tor browser where the timezone is forcefully set to UTC; this is why in general i continue to think that even if subject to an enabler, the user preference should be an option.

[evilaliv3]

@NSkelsey while we discuss this issue i've removed the current work i did from the devel branch.

@fpietrosanti could you please read the ticket and express your ideas on all the various topics?

[evilaliv3]

an additional detail to be used in our decisions:

the whistleblower using TBB will be always using UTC and we are not able to discern Tor/non-Tor users so probably adopting the detection of the browser timezone is not a good choice.

my last idea on the topic is:

• to have a node configuration for the timezone (to be used forcefully on Tor/non-Tor user)
• the possibility for a logged user to enable a custom timezone via an enabler and a configuration of the timezone.

any other approach would be too complicated and including failures; this instead works and we have simply to find a good UI to comunicate the adopted timezone (e.g. using CEST/PST etc)

[fpietrosanti]

I think the current implementation with automatic detection is fine and it's like most webapp does. Btw it make sense to provide the ability for the end-user to specify it's own timezone as a static preference, that would override the automatic detection.

[evilaliv3]

I agree that the current implementation of the detection is fine.

for now i've simply made the code uniform removing mixed used; let's remove the ticket from the current milestone and postpone improvements to the future.

as a resume for future development:

• on Tor browsers all dates will be shown always in UTC.
• it would be eventually possible to add a user preference for all users except the whistleblower; for the whistleblower we can consider to keep this preference encrypted associated to every tip and to reuse the language selection as the user return.