parse-dashboard
parse-dashboard copied to clipboard
parse-community
Time zone support
It would be great to have some way to specify the timezone to use when displaying dates in Parse Dashboard createdAt, updatedAt, etc.
Commenting on this as a vote, I would like to see time zone support as well.
I think you would make a lot of developers happy, looking at the +1s here. Do you have any idea on how you want to implement this?
Dear @mtrezza, I need this feature too, so very cool. Thumbs up! I start working on this :))
at the first, I need to add the time_zone parameter to the parse-dashboard-config.json, then only show the date-time in the selected timezone, for store date, send UTC date time to the server.
everything is alright?
I think that's a good approach - to start with the most simple form of the functionality. Later on, if someone wants to, they can add a UI to change that param in the dashboard.
What if someone enters a date via the date picker in the data browser. Should that be the local date and converted to UTC, or sent as it?
@pash2048 Here's something you might want to consider (just chipping in as the original opener of this issue, happy to see it might get picked up!)
I suspect most people would prefer to see these dates and times in one of two ways:
- UTC (existing behavior)
- Their current timezone
In my opinion, it would be awesome if instead of specifying a time_zone parameter, a flag could be set - perhaps use_local_timezone or similar. When true, it would use the browser's time zone setting to format the dates and times. When false (default), the existing behavior would apply. (I'm not much of a web guy, so I am making an assumption that the browser exposes some representation of the device's time zone).
This would better support distributed teams accessing the dashboard from different locations, as well as individual developers when moving between time zones.
Of course, supporting both approaches would be even cooler - perhaps your proposed time_zone parameter could handle a special case - it could be named local, automatic, or device for example. Setting time_zone to this value would display dates and times using the browser's timezone.
What do you think?
All great feature suggestions.
Depending on how much you (and others) feel like building, we can adapt the bounty amount accordingly. The 10$ bounty is probably just for a basic functionality.
What if someone enters a date via the date picker in the data browser. Should that be the local date and converted to UTC, or sent as it?
@mtrezza, I think it's better to be local date time and converted to UTC, for example, every time I need to enter a date in the parse dashboard, I convert my local date time to UTC and then enter a date. What's your idea?
@benpackard, thanks for your good suggestion, I think we can create it basically with the defined time zone in parameters and then add all features you said.
I think it's better to be local date time and converted to UTC, for example, every time I need to enter a date in the parse dashboard, I convert my local date time to UTC and then enter a date. What's your idea?
While I'm here, my feeling on this one is that if a date in my dashboard is displayed 7:00 pm, I should be confident that changing it to 7:05 pm adds exactly five minutes, regardless of the storage format. So IMO it should be entered in local time and converted to UTC automatically. The alternative is requiring the user to understand that she must enter the time in a format other than the one she sees, and having to manually covert the time correctly.
Good point @benpackard, I think I would expect the same behavior, it seems to be intuitive.
Bumping the bounty due to high demand.
Regarding the question of whether a date entered in the data browser should be UTC or local time, I'd expect it to be according to the dashboard time zone setting, because otherwise it wouldn't be possible to copy/paste date fields in the data browser.
It would be possible to add an option to the calendar input dialog to switch the input to UTC only for that one input. But that seems like a convenience add-on that may even be confusing to some, so maybe it's not really necessary in the first version of this feature.
