-
Notifications
You must be signed in to change notification settings - Fork 444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support per-user time zones #6082
Comments
The desired situation, in short: |
Instead of user-configurable time zones, I'd like to see us draw on the system clock. This is where working at the JavaScript level in the browser has a significant benefit and it should be possible for any UI components going forward. |
@NateWr, what about due dates sent by email? I suppose there's an implicit assumption that a due date is midnight per the assigning editor's local time zone, though this starts to get pretty fuzzy pretty fast. We could simply choose not to make assumptions about emailed dates and send them as is... |
@asmecher we don't allow times when setting a review due date, though we store it in a |
Agreed, @NateWr. I've been expecting a case to pop up from the back of my mind where we needed to supply time information to a user through a means other than their browser, but I can't think of a good one. 👍 to handling time zones via the browser. What about date formats (localization in particular) to boot? |
For localization of date formats I think we depend on existing translations. That was discussed in this comment. I suppose the two are going to be related. We'll need to get an overall datetime as |
If I remember correctly, what we're missing is a good If we only have dates in emails to consider for server-side formatting, a single strftime format string in the config file can handle that, and we don't need parallel implementations. |
I don't know if we'll ever be able to go fully browser or server rendering. Although For that reason, I'm leaning towards a browser-based |
I was looking at the
If we only really have one use case for PHP-based date formatting (emails), then we'd only need one (This isn't too different from using a |
I think the Themes are another place where we won't be rendering dates in JavaScript. We're also introducing, right now, a setting for date formats to be configured per journal and locale using I just don't think we're going to get around needing a common date formatter that we can use in the server and the browser. If all we need to support our languages is to ask our translators to provide day, week and month names, I think that they can provide that. |
We could use that to generate the translations. I'm hesitant to do that at run-time because it feels like code that shouldn't run on every request and we'd need to make sure it was all calculated before any other JavaScript executes. Another option would be to have a build script. A simple Node script could generate the necessary JS object whenever Either way I don't think this route would give us the necessary entries for the |
@asmecher would @Vitaliy-1's approach to mapping between |
👍 👍 👍 Yes, this is great. |
I notice that the map does not include some of the composite datetime formats that strftime supports. Is it ok for us to define a limited set of characters that we support? |
Yes, and perhaps to document those in the |
See https://forum.pkp.sfu.ca/t/per-user-timezone/59311.
Allow users to configure their time zone so that dates can be formatted more usably.
The text was updated successfully, but these errors were encountered: