Timezones

[anusenan]

We never had timezones in any requirements, but it seems like we need to agree on how to handle / not handle them, because they might impact travel through timezones.

[ewheeler]

So far we've directed vendors to keep everything in the database as UTC time (without timezone).

Then we can have frontend apps use each users' workspace's configured timezone to display offsets appropriately.

The biggest potential problem with this that we've identified:

since a trip's start_date value is a DateTimeField type which includes date and time, that means that when querying, for example, for all trips that begin on a certain date, then its possible that a start_date with a time near the beginning or end of the day would be excluded or including with the incorrect date's query results since the query is not aware of the user's workspace's timezone offset.

i'm not sure what the spec/business owners would say about having start_date include a time in addition to date, because users can only select the date in the user interface. to avoid this issue, we could either 1) default to noon which should avoid matching for the unintended date or 2) change this field to a DateField type that does not include hour/minute

[torbent]

@anusenan @ewheeler is there any news on this? we've suggested a few approaches, but we need a decision to move this forward. This is related to #90

[ewheeler]

from @janpanchalingam1

We are currently testing invoices and DSA and due to the time zone issue, DSA is not calculating correctly. For example:

• Traveller creates a trip: a. Depart/Arrive: June 7 from 2:30pm-4:30pm b. Return: June 7 from 7:59pm-8:00pm c. The result is that the DSA is 0, which is correct.

• Traveller updates the trip above: a. Depart/Arrive: June 7 from 2:30pm-4:30pm b. Return: June 7 from 8:00pm-9:00pm c. The result is that the DSA is 140% (1 day + 40% on the departure date), which should be DSA 0

[DonNicoJs]

@ewheeler @kasfaw @janpanchalingam1 @robertavram @torbent To address this bug and to summarise the whole discussion on this card:

To solve the timezone issue we have 2 path:

1) Frontend 'hack': Frontend 'discard' the timezone part and send the data to the server in UTC (but with the same time as non UTC)
Example: I am in +2 and I set 8:00 now we send to the server 6:00 UTC we will send instead 8:00 UTC. Frontend receive the data ( on load ) we drop the UTC timezone and show the UTC value as local time. Example: Backend send: 8:00 UTC frontend would show 8:00 (and not 10:00 being on +2)

PRO -CON: This solution is relatively easy to implement, but it will create 'false' data in the db, where you will have overlapping trip due to the 'timezone shift'. DSA calculation is untouched like this.

2) Complete solution: Frontend send data in local time plus timezones, backend register the timezones and use them during the DSA calculation.

PRO-CON: It's a big work that will require a lot of tests on the DSA calculation

[ewheeler]

thanks, @lordfuoco business owners have decided for now to go with the 3rd option of leaving as-is

in case this is revisited in the future, leaving some notes here as i'd think about expanding option 2 above to be a little more correct if we ever go that route:

when saving datetimes for trip things that have already happened or are currently happening, store as UTC with offset (so timestamps for things like submitted_at, rejected_at, approved_at etc saved as with the user's current local timezone offset like 2017-06-22T12:00:00-04:00). then we have the unambiguous UTC point of time as well as what to display that makes sense for the user.

for storing datetimes for trip things that will happen in the future, store as UTC with timezone name (like America/New_York or Asia/Tehran) which we can always use to calculate the precise time once the things occur (and probably right before they occur). For future events "at a minimum you will need the time zone, not merely an offset from UTC"

the reason is that if we just store UTC with offset then we risk being incorrect if the future event is after a daylight savings change. or after another change to a timezone--while not super common, these changes happen more often than you might think. for example, in January 2015, Chile announced that they would not be changing clocks as they usually do for DST in April 2015. So, if a trip were planned in December 2014 for dates after April 2015 then the trip times would be off by one hour which could conceivably affect DSA calculations or travel days. So, at time of DSA calculation (which presumably should be immediately before or during the trip) we would need to 1) take the UTC time with timezone name we stored previously, 2) grab the latest timezone data, and then 3) calculate the correct UTC offset to get the precise moment in time.

while this is probably the most complete solution, it will certainly add complexity and might not bring enough business value to be worth implementing

[mpawlowski85]

@aldohunicef @janpanchalingam1 please provide examples with wrong dates (email + action points). Also - please describe the desired behaviour. DSA is no longer relevant for this card

[janpanchalingam1]

Workspace: Jordan Browser: Chrome

Created action point with due date: November 30, 2017 at 8pm Email notification indicates due date: November 30, 2017 at 5am

Created a trip: December 29 at 8pm to December 30 at 8pm Email notification indicates trip is December 29 at 5am to December 30 at 5am

[aldohunicef]

discussion / pending

[janpanchalingam1]

@ntrncic @marko911 Start and end date is not being sent correctly on the front end. Nik and Marko to review and let product team know level of effort to fix.

[janpanchalingam1]

We have removed the clock from the overview to resolve this issue of timezones in the email notifications and on the front end.