Skip to content
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

Shelter stable dates from USE_TZ #3048

Closed
wants to merge 3 commits into from

Conversation

dato
Copy link
Contributor

@dato dato commented Oct 20, 2023

  • 28d1d46 Add failing test case for "January 1st" offset bug
  • 85f04f1 Shelter stable dates from USE_TZ

Some dates (publication dates, author dates) are meant as literals. What
the user inputs through a SelectDateWidget should be preserved as-is.
Django's otherwise-excelent support for timezones interferes with it (see
#3028).

Until a better fate of these columns is determined (do we migrate them to a
DateField?), and as a stop-gap measure, we can start being faithful to the
data by storing them in the Western-most timezone.

This is particularly important because 1/1/YYYY is a common pattern in
publication dates, given #743.

Fixes: #3028.


#3028 is somewhat intertwined with #743, because both work with the same columns. In general, I try to structure work in chunks that do something small and can be meaningfully applied.

With no need for a migration, I think this is a net win wrt the "shifting year" issue that was recently reported.

Furthermore, I believe in the future we might be able to deduce the correct tz conversions to apply. With this PR, I just offer a small tuning to affect/fix observable behavior.

Many thanks in advance for any reviews!

dato added 2 commits October 20, 2023 04:33
Some dates (publication dates, author dates) are meant as _literals_. What
the user inputs through a `SelectDateWidget` should be preserved as-is.
Django's otherwise-excelent support for timezones interferes with it (see

Until a better fate of these columns is determined (do we migrate them to a
DateField?), and as a stop-gap measure, we can start being faithful to the
data by storing them in the Eastern-most timezone.

This is particularly important because 1/1/YYYY is a common pattern in
publication dates, given bookwyrm-social#743.
@dato dato force-pushed the stable_dates_v0 branch 2 times, most recently from de44d4b to 0a39ec3 Compare October 20, 2023 12:09
@dato dato marked this pull request as draft October 20, 2023 12:39
@dato
Copy link
Contributor Author

dato commented Oct 23, 2023

Dropping in favor of #3059

@dato dato closed this Oct 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Dates wrong in ActivityPub Stream
1 participant