0

I know there has been a lot of talk on this topic and there are no magic answers about it.

But in the field of travel, we manage the local time of the place where we are traveling. for example. If I am in the United States and I reserve for an event in Japan I must adjust to the local time of that event in Japan.

There are places that observe the summertime, but others do not.

So whoever attends the event must adjust to the local time. So it does not matter much where the user is, but where the event will be.

Should I save in UTC equivalent to the local time of the event in the database, and then display and convert from UTC to the local time of the event in the template?

I am using with Django web framework

LuisSolis
  • 358
  • 3
  • 11
  • Sounds like a philosophical question... UTC for working, local time for living maybe ;-) – FObersteiner Jun 14 '20 at 17:26
  • See duplicate answers I linked. Several were asked with regard to other languages/platforms, but the approach and advice are the same. – Matt Johnson-Pint Jun 15 '20 at 17:02
  • Using timestamp will be good, or like your approach to use UTC time and then converting as per user timezone!! – Agent_Orange Jun 15 '20 at 17:04
  • I see no reason why this question should be marked as duplicate. Before posting the question, I read all of Matt's excellent answers. Django web framework time zone support is strict in storing dates in UTC. – LuisSolis Jun 15 '20 at 17:59
  • When I use a DateTimeField Django saves time in UTC in the database, then I will do the bellow: -Save the date in local time zone in DateTimeField (it will be saved in equivalent UTC+0 anyway. So I'll save the date in a Charfield) - Activate local time in form or template -Save time zone ID (from Olson db) in a CharField -Use this timezone to generate icalendar rrule (DTSTART;TZID=America/Bogota:20200615T125600 RRULE:FREQ=WEEKLY;) But in the frontend with javascript everything is complicated, it will be another problem to solve. Thanks @MattJohnson-Pint for your posts – LuisSolis Jun 15 '20 at 18:30
  • Hi Luis. From the perspective of how to store recurring events, it is indeed a duplicate, and I hope the answers I provided can give some guidance. With regard to Django storing strict UTC, you could ask about that particular aspect separately and hopefully a Django expert can provide an answer. If not, consider what I mentioned about "Alternative Approach" under [this answer](https://stackoverflow.com/a/19627330/634824). Cheers. – Matt Johnson-Pint Jun 15 '20 at 19:46
  • Also - I am not a Django expert, but there seems to be some ability to work with non-utc datetimes discussed in the documentation here: https://docs.djangoproject.com/en/3.0/topics/i18n/timezones/#naive-and-aware-datetime-objects – Matt Johnson-Pint Jun 15 '20 at 19:49
  • It is more complicated to use naive dates so I will not use it. Before writing this question, I checked your blog posts. They helped me a lot to understand how to work with time zones. I think I have solved it. now I'm a bit stuck with javascript. but I will solve it Thanks @MattJohnson-Pint – LuisSolis Jun 15 '20 at 19:58
  • 1
    Here are the links that have helped me a lot with this topic. in addition to those that are attached to the question: https://www.caktusgroup.com/blog/2019/03/21/coding-time-zones-and-daylight-saving-time/ / http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html / https://www.caktusgroup.com/blog/2014/01/09/managing-events-explicit-time-zones/ – LuisSolis Jun 15 '20 at 20:05

0 Answers0