0

My customer's store is in GMT +5:30 timezone but the user's locale is in GMT +8 timezone.

Currently, I'm using javascript's .toISOString() function to convert to UTC and storing UTC in the database. I retrieve UTC from the database and send exactly that the browser, so the new Date('2019-11-15T00:00:00Z') function converts the UTC to the browser's locale.

But, if the user opens a record created by GMT +8 timezone user or vice-versa, the dates are getting messed up.

I'm thinking it would be good if I can transfer the exact date the user enters in the browser and send that exact date to the backend to easily offset using the store's timezone?

The frontend is in VueJs and the backend is in C#.

Coder Absolute
  • 5,417
  • 5
  • 26
  • 41
  • What do you mean *precisely* by "the dates are getting messed up"? It sounds like things are behaving exactly as they should be. – Matt Johnson-Pint Nov 15 '19 at 16:51
  • Sure - things are behaving well if the user is in the same timezone as the Store. But things go weird if the user is in a different timezone as the store - the incorrect DateTime (UTC) are stored in the database. I'm looking for ways to avoid this. – Coder Absolute Nov 16 '19 at 08:07

2 Answers2

0

Always store UTC time in database

Just Store the UTC time in your database, In your client-side, Get client's current timezone,

Here, I am getting IANA timezone from client's system

// get client's timezone (From user's system)
var clientTimezone = Intl.DateTimeFormat().resolvedOptions().timeZone;

Then, Convert the UTC depends on the timezone and show it to user,

// assume 2019-11-15T00:00:00Z is the UTC date from your database
var convertedTime = new Date('2019-11-15T00:00:00Z').toLocaleString("en-US", {timeZone: clientTimezone});

Example

var clientTimezone = Intl.DateTimeFormat().resolvedOptions().timeZone;

var timeUtc = '2019-11-15T00:00:00Z';

var convertedTime = new Date(timeUtc).toLocaleString("en-US", {timeZone: clientTimezone});

console.log("Time to Current User : " + convertedTime);

var timeInUsa = new Date(timeUtc).toLocaleString("en-US", {timeZone: "America/New_York"});

console.log("Time in America (New York) : " + timeInUsa);

var timeInAustralia = new Date(timeUtc).toLocaleString("en-US", {timeZone: "Australia/Brisbane"});

console.log("Time in Australia (Brisbane) : " + timeInAustralia);
BadPiggie
  • 5,471
  • 1
  • 14
  • 28
  • I'm thinking to pass the DateTime as a string in this format `ddMMyyHHmmss` and then parse that in the backend and then offset using the store's timezone and store UTC in the database? But, passing the string format to the backend is the key... – Coder Absolute Nov 15 '19 at 14:35
  • So you want to store timezone also? Why are you increasing stored data? Above solution is hard? – BadPiggie Nov 15 '19 at 14:37
  • I don't want to store the timezone in the database, the database should always maintain the datetime in UTC. But I want to offset base on the store's settings rather than the browser's settings... – Coder Absolute Nov 15 '19 at 14:39
  • Exaclty, In above solution I am getting time zone from user's machine, So no problem even if user travel somewhere else, It will show the date and time according to user's current timezone – BadPiggie Nov 15 '19 at 14:39
  • Yes, if the user travels to another country then it must also show the data in store's configured timezone. – Coder Absolute Nov 15 '19 at 14:40
  • Some of my user computer's are having an incorrect timezone and it's not easy to remotely support them... So, I would like to avoid these problems as well. – Coder Absolute Nov 15 '19 at 14:42
0

Note that the js Date object is simply a number that represents an absolute time (independent of any timezone).

So the best encoding/format for transferring and storing a date is that number. IMO this is much simpler than storing a UTC string.

So, on the end-user's machine you would Date.parse the date string provided by the user and this would take account of the user's time zone for you and give you the absolute time number for sending and storing on your backend.

Don't do any formatting or parsing of dates on the backend if you are using Node because there are serious gotcha's and because you shouldn't need to anyway: any client device that needs a date string will do the formatting locally which will automatically convert it to the correct format for their locale and timezone. [edit: the Q did not specify the backend when I wrote this.]

You will need to watch for some gotcha's in the Date.parse function but these are minor compared to the node problems. The most significant IMO is that it will interpret dates in YYYY-MM-DD as ISO 8601 dates (which makes some sense) but then assume that they are GMT if no timezone is specified so you should make sure there is a timezone specified if you use that format.

Tom
  • 17,103
  • 8
  • 67
  • 75