times displayed are an hour ahead of times selected

[mordka]

Ha it's a good catch. We have internationalization problem. When user selects a date and save form -> the date should be converted from user's timezone the UTC and saved to database (https://github.com/mordka/fl-events/blob/master/both/collections/events.js#L211) When user is displayed a date we should read the date from database and convert it to user's timezone. (various places in the app) This can be a good reference for this problem: https://themeteorchef.com/snippets/handling-timezones/

[AndyatFocallocal]

If possible it would be better to simply have the time selected as the time selected, ignoring time zones. Facebook does this and it regularly causes issues for event organisers who are travelling (as a lot of ours will be), using a proxy, daylight savings changes, or just computer weirdness going on.

low tech, select a time, get a time is better

[ydaniel98]

@AndyatFocallocal How about a small popup on top of the page prompting the user to select a time zone (it would be saved as a user setting)? Also, the time zone could be specified where ever the time is displayed on the page.

[AndyatFocallocal]

@ydaniel98 i'm ok with that suggestion, if an automatic option is difficult or likely to have bugs

[mordka]

@ydaniel98 times are displayed in user's timezone by default so I don't see a point of selecting it ;)

[AndyatFocallocal]

@mordka Facebook has a lot of troubles with this system when people are travelling as it puts their profiles default timezone in when they create an event, so users set an event at 3pm, and it converts it for them to the middle of the night (i triple check after creating an event on the road).

the Gatherings map is going to used often by travellers wanting to meet people and do positive action together. is the auto timezone selection likely to cause any usability issues to those travelling?

if its a risk, simply having users select the time they want their event to start, and removing time-zones from the code entirely would be fine. simple and no risk of problems later. creator selects 3pm. user sees 3pm, its 3pm. they know which time zone they are in ;)

(ok, ok, it should be 24hr clock for the non-brits. ..user selects 15:00)

[ydaniel98]

@AndyatFocallocal @mordka I have not been able to find anything related to time zones in the code. It seems like they have not been taking into account at all.

[mordka]

The date should be saved in UTC format into database, when client is reading the date it converts to it's timezone. it's a browsers feature

Pawel

On Thu, Jan 19, 2017 8:21 AM, Edwin Daniel Penalo notifications@github.com wrote: @AndyatFocallocal @mordka I have not been able to find anything related to time zones in the code. It seems like they have not been taking into account at all.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[AndyatFocallocal]

@ydaniel98 @mordka my recommendation is just to shut this operation down. far simpler and no risks of issues relating to vpns or travel causing times to be set wrong, if we just save times purely in numerical format.

As an event organiser with FL for 5 years, i am repeatedly messed around by facebook, couchsurfing, meetup, etc, trying to predict what time zone i want my event in, or giving me the wrong details for an event in another country because i'm viewing it in from UK (or my computer still thinks its in the UK).

if it put 15:00, that's what i mean. if i read 15:00 thats what i expect.

[ydaniel98]

@mordka Thanks, I didn't know it was a browser feature. @AndyatFocallocal The fix was quite easy and no db modifications were required. If timezones are needed in the future, it should be quite easy to implement.

[AndyatFocallocal]

@ydaniel98 awesome! ᕙ༼ ,,ԾܫԾ,, ༽ᕗ