Dates for Prices - getting confused | Optimizely Developer Commun

Dates for Prices - getting confused

mark.hitchcock

Vote:

CMS version="11.4.0"
Commerce version="11.8.2"

Hi All,
We have a DXC hosted site for a client in New Zealand. Support have set the WEBSITE_TIME_ZONE to New Zealand Standard Time.

We get all our pricing data from an external system. The dates for the price is provided as just the date, no time compontent, however we have business rules from our client so set the time based on these rules. i.e. All ValidFrom dates have the time set to 00:01, 04/07/2018 -> 04/07/2018 00:01 (NZ date format - I've changed the uiCulture="en-GB" so this displays correctly in the EPi UI, en-NZ doesn't seem to work...)

Since dates for prices are saved in UTC, when we set the ValidFrom date on a price we use the following

var priceDetailValue = new PriceDetailValue();
...
...
priceDetailValue.ValidFrom = new DateTime(startDate.Year, startDate.Month, startDate.Day, 0, 1, 0, DateTimeKind.Utc);

Is this correct? Is there a better way of doing this? Should the server time be considered when setting this?

My understanding is when the date is displayed in the EPi UI it is converted from UTC to Local time, so since our client is in New Zealand, the ValidFrom date displays as 04/07/2018 12:01.

Can this be changed, via config/culture preferences/something else, so that it is displayed as 04/07/2018 00:01 ?
When a price is displayed on the NZ customer facing website how does the date time come into play? i.e. does it use the users browser to work out local time? Could they change their timezone and esentially get the price once it's expired?
How would these prices be displayed for someone in a different timezone, i.e. Australia

Any help in understanding this a bit better would be mich appreciated.
Mark

#194816

Jul 04, 2018 4:54

Quan Mai

Vote:

The date is supposedly UTC. So you can do this instead

price.ValidFrom = startDate.AddMinutes(1).ToUtc(); //pseudo code

and it is always converted to local time for display, based on the local time of the browser. So let say the time is 04/07/2018 00:01 (UTC), I will see it as 04/07/2018 02:01 (UTC+2), and someone from New York will see 03/07/2018 20:01 (UTC-4)

#194820

Jul 04, 2018 7:30

mark.hitchcock

Vote:

Thanks for the reply Quan.

So if the CMS users want to see the date in the EPi UI as 04/07/2018 00:01 in their timezone (NZ) what are our options? Should we be adding -12hr?

How would adding -12hr affect the price displayed on the customer facing site? i.e. would the PricingService still get the correct price for the day and time of the customer?

#194821

Jul 04, 2018 7:50

Quan Mai

Vote:

You should not have to. My memory is a bit rusty now (and timezone is always tricky), but IIRC then when you import the price then the timezone of the server will be used. The date will be saved as UTC in database and when the editors edit prices they will be displayed in their timezone. So you don't have to add -12 to the date time. You just need to make sure it is passed correctly.

#194822

Edited, Jul 04, 2018 8:18

mark.hitchcock

Vote:

Ok, I think I'm understanding this now. The timezone set for the server must come into play when the UTC date is saved since when the date is display using the same timezone it isn't offset at all when displayed.

For example. I've saved a date and time on the DXC server where the WEBSITE_TIME_ZONE is set to New Zealand Standard Time. If I change my timezone to NZ (UTC+12) close/reopen my browser, I can see the price is displayed correctly as 04/07/2018 00:01. If I change my timezone to say Perth (UTC+8) close/reopen my browser, I can see the price is displayed correctly as 03/07/2018 20:01.

So I think half the issue was the way the date was being set and the other half was how I was testing and ensuring that the browser is closed/reopened after changing the timezone, i.e. date.AddMinutes(1).ToUniversalTime(); is the correct way.

Thanks
Mark

#194828

Jul 04, 2018 9:57