Timezone Control in the GUIDE

[garrettmflynn]

This PR allows users to control the timezone used across the GUIDE from the Workflow page. Currently, this PR only allows you to select a timezone—not to actually apply this timezone to the resulting data.

@CodyCBakerPhD Still not 100% sure what the best way to propagate the timezone to the appropriate places in the backend? Would you be able to indicate how I should pass a timezone to NWB Inspector (e.g. using the validate_nwbfile_metadata function) as well as to NeuroConv during the conversion process?

This PR originated from a discussion following the merge of #790.

[bendichter]

I think this is likely to confuse people due to daylight savings time. Most of these timezone names actually have different offsets depending on the day of the year. zoneinfo takes care of this automatically- you input the name of the timezone and it will check the date so that the correct offset is applied. I wish we could apply a simplifying approach like this but honestly I think this is going to confuse a lot of people if implemented this way

[bendichter]

I honestly think a very long dropdown would be better. I know it's not ideal but it is at least accurate

[garrettmflynn]

Just pushed the option where we are rendering the browser's acceptable timezones as a native <select> element.

How's this? Would you prefer it to be searchable? What about the formats used by zoneinfo that aren't in America/Chicago format?

[CodyCBakerPhD]

This approach would absolutely need to be searchable (probably as our loose selector); it's overwhelming scrolling through a list that massive

I'd still recommend we simplify with a basic numeric scroller, that's many fewer options and removes the complexity of tying the number to a specific place (which has a somewhat low chance of being exactly the city they are located in)

[bendichter]

I guess a simple alternative would be to just provide offsets without names

[CodyCBakerPhD]

I guess a simple alternative would be to just provide offsets without names

I think this might be best overall

I really worry about

I honestly think a very long dropdown would be better. I know it's not ideal but it is at least accurate

Because we already get feedback in user tests about information overload

And basic google search of 'what time zone am i in' (maybe we can have a description hyperlink find my timezone somewhere?) reports the offset for GMT, so I don't think it's unreasonable for users to be responsible for looking up their own timezone if they don't know it

[garrettmflynn]

@CodyCBakerPhD Can you take a look at this? Almost ready, just think we need to adjust NWB Inspector to allow for adjusted timestamps. At present, a timestamp that is correctly rejected will not have a reaction when the GMT offset is added.

[CodyCBakerPhD]

I don't see a timezone area on the session start time selector for the file metadata page

Was there something else you wanted me to look at?

[garrettmflynn]

Oh sorry, this just implements a global configurable timezone on the Workflow page.

Implementing a field-level selector will be significantly more complicated, if only for the back-and-forth we'll need to finalize the UI. Should squeeze that in with an optional time—as those UI components are going to have to play nice together.

[rly]

Could we make the user's current time zone appear first in the list? That's the most common case.

Secondly, could we enable search on any part of the time zone name? E.g. currently searching "new" does not return anything. I have to start with "America/New"

[rly]

I found some interesting ux data on time zone selectors: https://www.nngroup.com/articles/time-zone-selectors/
(TL;DR guide at the bottom)

[CodyCBakerPhD]

Oh sorry, this just implements a global configurable timezone on the Workflow page.

Ah, thanks I missed that

If I click off of the selector mid-choice it autofills with this

and I have to delete it to get back to valid choices

I can also proceed to the next pages with undefined but if I go back it reverts to Pacific/Tongatapu for some reason

I would also make this a required field (red asterisk)

[CodyCBakerPhD]

Also when I try to create a non-stub file I get this error displayed

But no console.log or log file contains a traceback - is this something on the frontend?

[CodyCBakerPhD]

@garrettmflynn This should be working now, can you give it a whirl?

One thing is I may have broken that nice section rendering of the zoneinfo loose selector (by 'America' and so forth) but it at least seems functional

[garrettmflynn]

Looks good! That change is on me, I've added it back now that we're pulling from the Python list.

[CodyCBakerPhD]

Oky doky, last thing is just fixing the tests then this is good to go

[CodyCBakerPhD]

@garrettmflynn According to chromatic, this PR also introduces the 'edit default values' button to all source data pages'?

There also seem to be 3 missing story pages: https://www.chromatic.com/build?appId=640a4d93e34604f275368983&number=997

Any idea what that's about?

[garrettmflynn]

Yes working on it now. Seems to be something we didn't catch during the refactor after trying to remove the dev (web) mode.

The stories rely on storyStates.ts and saving / loading progress files—which was, in large part, removed.

Some of this was that I wasn't providing a timezone properly without backend access. But there's more to the story than that.

[garrettmflynn]

Should be fixed. A lot of this also had to do with the addition of the Workflow (Preform) page.

[CodyCBakerPhD]

Great, thanks!