Pre-set user's timezone

[MaybeThisIsRu]

Is your feature request related to a problem? Please describe. I signed up and saw you can set a timezone. It was set to UTC by default.

Describe the solution you'd like JavaScript has an Internationalization API that returns timezones. At attempt should be made to pre-set this for less friction.

const x = new Intl.DateTimeFormat()
x.resolvedOptions().timeZone
// => "Asia/Kolkata"

Reading:

• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/resolvedOptions

[mouse-reeve]

Almost every thing is done in Django, so JavaScript may not be able to help here, but I think Django can make a decent guess at timezones based on request headers

[MaybeThisIsRu]

You're right, I think it can – what headers would be helpful here? Just curious to see if they're not a mess even though the standard is clean. :)

Originally, I thought of sending a hidden input with the timezone name at sign up and using that at some point down the line. HTTP headers would be every bit better.

[MaybeThisIsRu]

Makes for some interesting reading, this: https://django.readthedocs.io/en/3.2.x/topics/i18n/timezones.html#selecting-the-current-time-zone

The current time zone is the equivalent of the current locale for translations. However, there’s no equivalent of the Accept-Language HTTP header that Django could use to determine the user’s time zone automatically. Instead, Django provides time zone selection functions. Use them to build the time zone selection logic that makes sense for you.

Most websites that care about time zones ask users in which time zone they live and store this information in the user’s profile. For anonymous users, they use the time zone of their primary audience or UTC. pytz provides helpers, like a list of time zones per country, that you can use to pre-select the most likely choices.

[redshiftss]

On a related note, I was looking into fixing this and it seems like bookwyrm still uses pytz, but zoneinfo was made the official timezone implementation in django according to this (https://docs.djangoproject.com/en/4.1/topics/i18n/timezones/). Should we switch to zoneinfo or continue using pytz?

[mouse-reeve]

It would be good to switch to zoneinfo -- we're still using Django 3, which is why pytz is in use, but I'd like to get to Django 4 and that would be a helpful step towards it.

[redshiftss]

I've been having a look at this - two things : it seems like django does a very bad job at guessing - it just defaults to UTC (which isn't any better than what it currently is doing...) and headers don't seem to be useful, but I'll try and implement something with hidden fields like @MaybeThisIsRu suggested, I think that will work