Storing wall-clock datetimes in Django/Postgres

问题

I want to save a future wall-clock datetime for events in Django (I have timezone string stored separately).

I can't simply use the DateTimeField because it enforces timestamp with time zone and always saves time in current timezone. It doesn't handle DST or possible timezone changes between current date and the date of actual event.

I could use any of these options:

• Pick any timezone to store timestamps and always throw this timezone away before applying actual timezone in Python.
• Split timestamp to DateField and TimeField.
• Store datetime as string.
• Custom field that stores datetime as timestamp without time zone.

but it makes queries more difficult and seems quite weird.

Are there any better options I miss? This usecase seems quite common so I guess there is a better way to do that?

EDIT: my usecase:

Let's say my user want to book an appointment to 2019-12-20 10:00 and currently it's 2019-03-10. I know the timezone of this user (it's stored separately as string like 'US/Eastern').

If I assume that EST starts at November 3, 2019, the best I can do is to store timestamp to 2019-12-20 15:00:00+00:00 (or 2019-12-20 10:00-05:00. I don't want this because:

• I have no idea if my tzdata has correct information for future datetime
• Even if it currently does, I have no idea if there would be any unexpected change in US/Eastern timezone and it becomes worse when it's not US. Future DST changes are not guaranteed.
• If user moves to different timezone, I'll have to recalculate every single appointment while taking care about DST.
• If tzdata changes during this recalculation... let's not think about that.

I'd prefer to store future dates as naive datetime + timezone string like 'US/Eastern' and (almost) never construct tz-aware datetime for any date further than a week. Django + postgres currently forces me to use timestamp with time zone, which is great for logs and past events, but it has fixed offset (not even timezone name) so it doesn't fit for future wall clock datetimes.

For this usecase, let's say that I don't care about ambiguous times: not much users want to book at 02:00 AM.

回答1:

I see a few possible solutions:

1. Set USE_TZ = False and TIME_ZONE = 'UTC' and use calendar times. No conversions will be done, so essentially you're just storing the calendar time and getting it back as a naive datetime. The main problem is that this setting is global, and is not a good one for many uses (e.g. auto_now).

2. As above, but set USE_TZ = True. As long as you express your calendar times in UTC, there won't be any untoward conversions. The problem here is that you'll be getting aware datetimes, so you'll have to take care to ignore or remove the time zone everywhere.

3. Use separate DATE_FIELD and TIME_FIELD. This may or may not be a good solution depending on what kind of queries you're trying to run.

4. Create your own field that uses timestamp without time zone. (Or perhaps it already exists?)

Note that this issue has nothing to do with past versus future. It's about wanting to use a fixed moment in time versus a calendar (or wall clock) time. The points you raised are certainly valid objections to using a point in time to represent a calendar time.

来源：https://stackoverflow.com/questions/55101547/storing-wall-clock-datetimes-in-django-postgres