As a complement to the proposed solution in https://github.com/CartoDB/cartodb/issues/12087 we should implement a time-zone drop down menu selector in the Time-series widget itself, implying:
· That will only appear if the widget is based on a a time stamp and not a numeric value
· That it will override, for the active viewer, the time-zone configuration originally chosen by the builder in he widget config.
cc @CartoDB/design for some mock-up magic
When the user has selected a timestamp column, inside the widget will be a dropdown where the viewer could change the Time Zone.


cc/ @CartoDB/design
Why not moving that option within the "..." menu?
El jue., 4 may. 2017 a las 13:36, Juanma (notifications@github.com)
escribió:
When the user has selected a timestamp column, inside the widget will be a
dropdown where the viewer could change the Time Zone.[image: widgets - time series 014]
https://cloud.githubusercontent.com/assets/14546701/25701878/99698828-30ce-11e7-93ad-705a7b2453cf.png[image: widgets - time series 015]
https://cloud.githubusercontent.com/assets/14546701/25701881/9de5ecac-30ce-11e7-9867-de607c6af89c.pngcc/ @CartoDB/design https://github.com/orgs/CartoDB/teams/design
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/CartoDB/cartodb/issues/12088#issuecomment-299160922,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIENZgX4tKmLZKcWzrmzl_F0JZcBbW1ks5r2bhOgaJpZM4NQUXC
.
UPDATE: We've decided to put a Local timezone switcher under the ellipsis menu.
Updated


Why have we added the type selector? It will depend on the format of the data so I'm not sure we will be able to change it
@saleiva, following a conversation with @rochoa that decision needs some technical research; we'll have news soon. In any case, this discussion belongs to the other ticket, this is only for the public view.
ok, giving some time to @rochoa to evaluate. Anyway, that TYPE selection shouldn't be there. It's a potential source of problems and we can check from the client the type of the chosen column.
Hey mates focus, please. We have to validate if the switch under 3 dots icons to change to "Local Time Zone" it's a good solution and if it solves the problem.

The settings for the widgets is on this ticket https://github.com/CartoDB/cartodb/issues/12087
@urbanphes looks very good to me.
validated! it's perfect
When time series data is loaded in, how does the user indicate what time zone it is in? Is this a required field?
WITHDRAWN: I see this is addressed in #12087
Hi all.
I see the local timezone toggle very useful for the embed but... what happens in Builder?
According to the visuals, in Builder we could have two different timezone selectors for the same target. Should they be sync'd? What happens if I set the widget local timezone on? We should modify the one in the options panel?
I think this is potentially error prone since we have two sources of truth for the same widget. Maybe we can show the toggle only in embed views.
Any thoughts?

Sounds good to me (only showing the toggle in the embed)...
Also, if you go back to the original message, Noguerol said:
That it will override, for the active viewer, the time-zone configuration originally chosen by the builder in the widget config
So yeah, it would override it while the toggle is on.
Can we change the name of the input field on the left side to "Default Time Zone" to make it more clear what the behavior is here?
Also, I don't love the use of "Aggregation". It is a bit technical. Can we use "Split" or something more user friendly? What values does this field accept?
Also, under Behavior, what does "yes / no" mean in terms of "Aggregation"?
Quick and fast:
Confirming that I agree with Sergio - if "Aggregation" is a term we use
elsewhere in Builder, we should use it in this feature.
We will investigate changing it everywhere at some different time.
--
Kevin Reilly
SVP Product
CARTO https://carto.com/ | [email protected] kevin@carto.com
(917) 375-2168
On Tue, May 23, 2017 at 9:07 AM, Ivan Malagon notifications@github.com
wrote:
>
- It's a typo. It says Dynamic in the UI.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/CartoDB/cartodb/issues/12088#issuecomment-303391759,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACy_X79VERuoUMPVzH7GlGuGYWTEH-Xxks5r8toGgaJpZM4NQUXC
.
Both time zone toggles should be shown, as the one in the widget overrides the one in the config and that behavior should also be testable within Builder. In other words, the LI app in Builder should always be the same as the LI app itself.
Blocked until https://github.com/CartoDB/cartodb/issues/12324 is finished and deployed.
first of all, sorry to add literature to the already long topic, I've been working in the widget timezone selector and found some issues
while the timezone implementation works like a charm I had to wrap my head around how to use it, as passing it as the sole parameter just offset the data (see attached)


after discussion with @dgaubert I'm offsetting the start and end parameters too, and it produces the desired effect, however this is a _HACK_ and needs to be eventually sorted out at Engine level

as a heads up I also added the whole list of timezones in moment-timezone but I think some more work needs to be done because right now there are repeated timezones thus selecting several items in the dropdown, I'm probably grouping them

I've piggybacked @ivanmalagon PR #12347 on a separate branch (cartodb, deep-insights, cartodb.js) 11649-play-12324-time-series-aggregations
Great summary @matallo! About the problem in engine, @jorgesancha or @noguerol should decide if they need to tackle it or not, but in my opinion, the sooner the better. Then, further to the dropdown, IMHO, I'd group them to display a few, not all of them and make the dropdown cry.
+1 to grouping, let us know if you guys need help from design with that.
Also, shouldn't we display the time zones in UTC instead of GMT?
We should group them, yeah. Time zones are always GMT afaik, right?
I have some WIP and will be able to show very soon, based in these groups https://msdn.microsoft.com/en-us/library/ms912391(v=winembedded.11).aspx
Unblocking this after merging aggregations 💃 .
Blocking issue. @dgaubert is fixing the API to address a problem with bucketing in edge cases. As soon as it's available in the API we can unblock this.
On it... I'm finishing some refactor
On Tue, Aug 8, 2017 at 10:00 AM, Ivan Malagon notifications@github.com
wrote:
Blocking issue. @dgaubert https://github.com/dgaubert is fixing the API
to address a problem with bucketing in edge cases. As soon as it's
available in the API we can unblock this.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/CartoDB/cartodb/issues/12088#issuecomment-320881683,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB2N-KxL9VDmNqCA7wP7j-kJD9dbT5MSks5sWBW3gaJpZM4NQUXC
.
--
Daniel García Aubert
Developer
CartoDB
Plaza de Callao 4, 2 28013 Madrid
www.cartodb.com
Fixes in Tiler already released: https://github.com/CartoDB/Windshaft-cartodb/releases/tag/3.11.0
BOOM
On Tue, Aug 8, 2017 at 12:22 PM, Daniel notifications@github.com wrote:
Fixes in Tiler already released: https://github.com/CartoDB/
Windshaft-cartodb/releases/tag/3.11.0—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/CartoDB/cartodb/issues/12088#issuecomment-320915322,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACPRBKplHq0GpcBA_FohhQfuKDJBmu2ks5sWDb0gaJpZM4NQUXC
.
--
Carlos Matallín
UI developer
CartoDB—Map Your World's Data
Plaza de Callao 4, 2 28013 Madrid
T: +34911165823
W: www.cartodb.com
Live sessions to learn CartoDB http://cartodb.com/webinars/
In staging, when selecting a different timezone in Builder I see no changes when selecting my local timezone on the embed.
Carto here:
twitter_t3chfest_reduced map (on 2017-08-09 at 08.29.17).zip
Besides, two visual minor things:



In staging, when selecting a different timezone in Builder I see no changes when selecting my local timezone on the embed.
Just an obvious question, did you re-publish the map? It happens to me all the time
Regarding embed.
You will only see changes in datasets that are aggregated by minutes, hours or days. In this last case only if there is data that changes of day because of the timezone offset. Please refer the dataset you're using to see if there are really no changes.
Regarding 1.
OK.
Regarding 2.
We agreed that the end selection label should be the previous one.
In your two screenshots:
It's the right behaviour.
Mata, Ivan, try with the attached .carto. I select a +12 timezone, which implies day changing in that data, republish the thing and the embed doesn't changes. Maybe I'm missing something.
As per the labels, you're right I'm wrong 🙄 That doesn't mean it's entirely well solved visually talking. Maybe we can align ranges labels inwards so they are more obviously related to what's selected. I'll have a quick look with design.
That doesn't mean it's entirely well solved visually talking.
That's impossible 😛
Didn't see the .carto. You're right. There is a problem there. Taking a look.
Ok, so about the labels. To prevent that overlapping its better to align the label not to the dragger but to the bin itself. I attach some mocks:


Which drives us to a new bug, the cropped label on the time series limits:

Are those changed promoted by @CartoDB/design ?
My concern is: with that approach the position of the labels are dynamic and dependant on the bin width. Sometimes they'll wide as in your screenshot but other times we'll have 365 bins and it won't be clear where the label belongs. Moreover, that will show a non consistent look & feel.
Anyway, this change + bug is not related at all with this issue (timezone selection) so in case we need to tackle those two tasks please open a new ticket.
Ready for another round of acceptance at ded05!
Issues fixed:
vamooo
@CartoDB/design, it would be great if you can take a look too.
It was proposed by us @ivanmalagon 🙂 but thaaaanks for the ping nonetheless! 💕
Taking a look.
I have found a few things:




Oh, super nice feedback, thanks @arianaescobar :kiss:.
Nice catchs Ari.
SInce most of them are not related to changes introduced in this PR (they're already happening in production) I've included them in a next ticket. This issue deals with filters so it's a good candidate to make changes to the range filter.
I'm taking a look on the dropdown ones. One of them it's likely to be happening Builder-wide.
Ready for another round of acceptance at ded05. (you can use user busta-05)
Issues fixed:
Merged last fixed issues from master
Perfect ✨
It works like a charm ✨
I have some improvements though to be tackled in a different issue:
From a user point of view, the toggle vs timezone field may be confused, at least it was for me during the acceptance. Basically, if the toggle is on, the timezone field is kind of useless in Builder, because you won't see any change in the chart while the toggle is on. I wonder if we could improve it, maybe deactivating this field in Builder in this case, or warning the user this field only concerns to publication because you are using your local timezone. I know this can be rough from the technical point of view, because of the communication Builder <-> widgets.
Also, in the embed, the user has no information about the timezone chosen in Builder time. She knows she can use her local timezone but nothing more.
If the local timezone matches with the timezone chosen in Builder time, the toggle in the embed is useless, and it could lead the user to perceive the interaction as a failure. Should we hide it if they both are the same?
As I said, I see these as a separated issues to improve the feature.
Thoughts?
Why not adding the "timezone" after the time in the title location?
cc @CartoDB/design
@nobuti wanna join the design team?
You're SO right.
@arianaescobar \o/
Deploying and opening a new issue.
Most helpful comment
Nice catchs Ari.
SInce most of them are not related to changes introduced in this PR (they're already happening in production) I've included them in a next ticket. This issue deals with filters so it's a good candidate to make changes to the range filter.
I'm taking a look on the dropdown ones. One of them it's likely to be happening Builder-wide.