Best practices to create and store time zone independent date and time from JS to DB

Viewed 26

What is the practical way used in industry to create and store date and time which is independent of time zone and user client time zone.

Let's consider example with events and festivals. I am administrator of some events web page written in Javascript as front end. Events are stored in Database and dates for those events are in string format (or Date object in sql DB, but it has no time zone info).

From GUI, while sitting in New York I want to create event for United Kingdom. Let's take date 2022-09-30 18:00.

As JS client in UTC-4 timezone, creating date gives result of:

const date = new Date(2022, 8, 30, 18);
//Fri Sep 30 2022 18:00:00 GMT-0400 (Eastern Daylight Time)

When converting Date object to JSON to send to server it is converted to ISO string

'2022-09-30T22:00:00.000Z'

My server has it's timezone set to 'Europe/Helsinki', so it takes UTC date from JSON, converts in JAVA to Date object and output is.

Sat Oct 01 2022 01:00:00 GMT+0300 (Eastern European Summer Time)

And in the end formats as string below and saved in DB (not sure if it is string actually, as in SQL it is Date type, but printing value from DB gives a string)

'2022-10-01 01:00:00.000'

When user in Sydney opens this event server take date from DB assuming it is saved in server time zone, creates Date object from '2022-10-01 01:00:00.000' and passes it to client as JSON string.

'2022-09-30T22:00:00+0000'

So in the end, unless server time zone does not change, ISO time received while saving date and then sent as response when querying from database is always the same.

The issue comes when client in Sydney converts date string to Date object and gets

Sat Oct 01 2022 08:00:00 GMT+1000 (Australian Eastern Standard Time)

So in the end GUI show him that event happens in UK Oct 01 2022 08:00:00 instead of Fri Sep 30 2022 18:00:00

I tried to fix this issue by calculating offset of server time zone using moment-timezone library. I got offset of client from UTC at specific date and offset of server from UTC at specific date and then subtracted difference. For example:

Offset from NY time and Server time at specific date (Fri Sep 30 2022 18:00:00) is 7 hours (420 minutes).

So when creating date object I consider offset 7 hours subtract them and in the end server saved date string to DB which is exact date event takes place

'2022-09-30 18:00:00.000'
//Fri Sep 30 2022 18:00:00 GMT+0300 (Eastern European Summer Time)

This has some issues though

  1. I need to store servers timezone as constant in client so no matter where client is located it can add offset difference from his time zone and server time zone to display correct date and time
  2. In case of server time zone changes, I need to change that constant
  3. I could use UTC time in server so I can use new Date(Date.UTC()) constructor when creating dates in client so it is already created date with offset from server time zone.
  4. Above is not perfect as I need to refactor a lot of code where new Date() is used to use Date.UTC constructor.
  5. Also I need to do changes to dates that already exist in DB to have offset from previous timezone of +3 to UTC time zone (date already are incorrect in DB, so it is not biggest issue).

I have chosen solution explained because I still need to manipulate Date object in client, so actually I only calculate offset in service when posting and getting requests/responses, which is convenient as no code in other places needs refactoring. Though it may have issues stated above and not all my dates that are passed to server need to be fixed dates, so it is hard to keep good logic in services.

What would be best practices to store fixed dates? I can't think of any other solutions than:

  1. Refactor code where fixed display dates are needed and save in UTC format using Date.UTC constructor and parse these type of dates using Date.UTC constructor and then display as toUTCString (of course formatting without time zone). But changes in server side code not considered so in case of server changed time zone, wrong UTC time will reach client due to JAVA date conversion from DB to JSON.
  2. Save as plain string or object with year, month, day, etc. But I can not be guaranteed that this format will be persistent as it is non-standard.
  3. So in the end I want to keep ISO standard format of date-time string, but then I need to be aware of server time zone when calculating offset.

Any suggestions how these situations are handled in practice?

0 Answers
Related