Open
Description
It would be great to have some way to specify the timezone to use when displaying dates in Parse Dashboard createdAt, updatedAt, etc.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
Vortec4800 commentedon Sep 4, 2016
Commenting on this as a vote, I would like to see time zone support as well.
tarekskr commentedon Dec 10, 2016
+1
mistahgandhi commentedon Feb 11, 2017
+1
yomybaby commentedon Feb 23, 2017
+1
AnChiChang commentedon Mar 17, 2017
+1
imMatt commentedon Jul 21, 2017
+1
xcarpentier commentedon Jul 26, 2017
@flovilmart any idea on this topic?
onosol commentedon Nov 23, 2017
Bump - this would be an ideal feature. +1000
jenlai1345 commentedon Feb 14, 2018
+1 please
skparticles commentedon Mar 2, 2018
+1
ananfang commentedon Apr 3, 2018
+1
AlexShul commentedon Apr 3, 2018
+1
15 remaining items
mtrezza commentedon Jun 6, 2022
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?
benpackard commentedon Jun 6, 2022
@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:
In my opinion, it would be awesome if instead of specifying a
time_zoneparameter, a flag could be set - perhapsuse_local_timezoneor similar. Whentrue, it would use the browser's time zone setting to format the dates and times. Whenfalse(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_zoneparameter could handle a special case - it could be namedlocal,automatic, ordevicefor example. Settingtime_zoneto this value would display dates and times using the browser's timezone.What do you think?
mtrezza commentedon Jun 6, 2022
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.
pash2048 commentedon Jun 8, 2022
@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.
benpackard commentedon Jun 8, 2022
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.
mtrezza commentedon Jun 8, 2022
Good point @benpackard, I think I would expect the same behavior, it seems to be intuitive.
apederse commentedon Oct 10, 2023
+1
mtrezza commentedon Oct 10, 2023
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.
badboy-tian commentedon Apr 12, 2024
+1 need
mtrezza commentedon Apr 12, 2024
Maybe something @AshishBarvaliya would be interested in :-) This feature is quite a record breaker, open since 2016 and continuously in demand until today.
Bhavyajain21 commentedon May 4, 2024
Is this still open?
I'd like to work on this. Please assign @mtrezza
mtrezza commentedon May 4, 2024
Yes it is, please feel free to pick this up
sonivaidehi commentedon Nov 28, 2024
+1 we need this feature.