CODEWITHSUNDEEP
c#.netdatetimetimetimezone
Aaron Zhong
Aaron Zhong

Reputation: 1022

Best practice for working with DateTime in C# relative to a user's local timezone

I have an application with discount/deals for items that need to be configured to be enabled between specific datetimes i.e. 1st January 2022 7:00 am to 31st January 2022 5:00 pm.

The user which sets these start and end dates can be based anywhere in the world but the end consumers need to observe these start and end dates relative to their local time.

For example, the user setting up the deal is in Malaysia GMT+8 for their end consumers across Indonesia (which has 3 separate time zones GMT+7, GMT+8 and GMT+9) as well as some other end consumers in New Zealand (which has daylight savings and alternates between GMT+12 and GMT+13)

So, a consumer in GMT+13 must observe the deal being available in 1st Jan 7am while another consumer in GMT+7 will observe it a few hours later but still 1st Jan 7am in their local time.

They observe these deals 1. On an app on their phone and 2. In-store where they claim these deals. So even though consumers could change the time zone on their phone to see the deal being available sooner - they must go in-store to claim them and can only do so once the timezone of the store reaches the available time.

My current thought process is to store these without any time zone into using a DateTime type with Unspecified kind and any usage of this DateTime will be relative to the consumer/stores local time configured on the device. I don't see a way to do this with saving this date as UTC

Are there any alternative approaches? Is there better support with this use case by using the new DateOnly and TimeOnly structs?

Upvotes: 0

Views: 1369

Answers (1)

Matt Johnson-Pint
Matt Johnson-Pint

Reputation: 241525

My current thought process is to store these without any time zone into using a DateTime type with Unspecified kind and any usage of this DateTime will be relative to the consumer/stores local time configured on the device.

Yes, that would be appropriate for the scenario you described.

This is sometimes referred to as a "floating time". You might also see it described as "television time", because such scenarios are common in broadcast television with regard to the time a show is aired.

Keep in mind the following:

  • When you store or transmit these values, do not treat them as UTC or associate them with any particular offset. Just use the date and time.

  • When you use these values on the user's device, you can apply the local time zone without actually knowing what that time zone is. For example, in .NET you can use TimeZoneInfo.Local or DateTimeKind.Local. In JavaScript, you can use the Date object, etc.

  • When you use these values elsewhere, such as in a back-end system, scheduler, or administrative UI, you will nee to know the user's time zone ID. Treat the value as belonging to that user's time zone, then convert it to a DateTimeOffset before comparing it to other values. For example:

    TimeZoneInfo tz = TimeZoneInfo.FindBySystemTimeZoneId(userTZ);
TimeSpan offset = tz.GetUtcOffset(dt);
DateTimeOffset dto = new DateTimeOffset(dt, offset);

if (dto >= DateTimeOffset.UtcNow) ...

Upvotes: 2

Related Questions