Getting Time Zone from DateTimeOffset [duplicate] - c#

I am calling a service which standardizes a given address and also gives timezone of the result in UTC offset (ex: -5:00 etc).
Is there a function in C# which takes in timezoneoffset of UTC and calculate timezone(Three characters such as CST, EST, PST) ?

No. That's an impossible request in any language, because:
Many different time zones share the same offset.
There is no standard for time zone abbreviations. There is a lot of overlap and ambiguity. For example, "CST" has at least 5 different meanings that I am aware of.
Even if you limit yourself to the United States, you cannot reliably distinguish between offsets. For example, -5 could be EST or it could be CDT.
There is even one hour a year where EST and CDT are BOTH in effect at the exact same time. For example, this occurred on November 2, 2014, when 1:00 AM EST and 1:00 AM CDT were both in effect simultaneously, and both used the UTC-5 offset.
I am calling a service which standardizes a given address and also gives timezone of the result in UTC offset (ex: -5:00 etc).
Unless the service is returning the offset for a specific date and time, then it could be lying to you. Perhaps it is returning the current offset, but that is not fixed. The same location can cycle through multiple different offsets.
IMO, Services like that should not attempt to resolve an offset, but should instead return a time zone identifier, such as America/New_York.
You should probably read the timezone tag wiki, and you may also be interested in this post.

If there is any chance of doing this in C#, I would think NODA Time would do it.

Related

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?
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) ...

Is there any delivered method which takes in timezoneoffset of UTC and calculate timezone in C#?

I am calling a service which standardizes a given address and also gives timezone of the result in UTC offset (ex: -5:00 etc).
Is there a function in C# which takes in timezoneoffset of UTC and calculate timezone(Three characters such as CST, EST, PST) ?
No. That's an impossible request in any language, because:
Many different time zones share the same offset.
There is no standard for time zone abbreviations. There is a lot of overlap and ambiguity. For example, "CST" has at least 5 different meanings that I am aware of.
Even if you limit yourself to the United States, you cannot reliably distinguish between offsets. For example, -5 could be EST or it could be CDT.
There is even one hour a year where EST and CDT are BOTH in effect at the exact same time. For example, this occurred on November 2, 2014, when 1:00 AM EST and 1:00 AM CDT were both in effect simultaneously, and both used the UTC-5 offset.
I am calling a service which standardizes a given address and also gives timezone of the result in UTC offset (ex: -5:00 etc).
Unless the service is returning the offset for a specific date and time, then it could be lying to you. Perhaps it is returning the current offset, but that is not fixed. The same location can cycle through multiple different offsets.
IMO, Services like that should not attempt to resolve an offset, but should instead return a time zone identifier, such as America/New_York.
You should probably read the timezone tag wiki, and you may also be interested in this post.
If there is any chance of doing this in C#, I would think NODA Time would do it.

Representation of a DateTime as the local to remote user

Hello!
I was confused in the problem of time zones. I am writing a web application that will contain some news with dates of publication, and I want the client to see the date of publication of the news in the form of corresponding local time. However, I do not know in which time zone the client is located.
I have three questions.
I have to ask just in case: does DateTimeOffset.UtcNow always returns the correct UTC date and time, regardless of whether the server is dependent on daylight savings time? For example, if the first time I get the value of this property for two minutes before daylight savings time (or before the transition from daylight saving time back) and the second time in 2 minutes after the transfer, whether the value of properties in all cases differ by only 4 minutes? Or here require any further logic? (Question #1)
Please see the following example and tell me what you think.
I posted the news on the site. I assume that DateTimeOffset.UtcNow takes into account the time zone of the server and the daylight savings time, and so I immediately get the correct UTC server time when pressing the button "Submit". I write this value to a MS SQL database in the field of type datetime2(0).
Then the user opens a page with news and no matter how long after publication. This may occur even after many years. I did not ask him to enter his time zone. Instead, I get the offset of his current local time from UTC using the javascript function following way:
function GetUserTimezoneOffset()
{
var offset = new Date().getTimezoneOffset();
return offset;
}
Next I make the calculation of the date and time of publication, which will show the user:
public static DateTime Get_Publication_Date_In_User_Local_DateTime(
DateTime Publication_Utc_Date_Time_From_DataBase,
int User_Time_Zone_Offset_Returned_by_Javascript)
{
int userTimezoneOffset = User_Time_Zone_Offset_Returned_by_Javascript; // For
// example Javascript returns a value equal to -300, which means the
// current user's time differs from UTC to 300 minutes. Ie offset
// is UTC +6. In this case, it may be the time zone UTC +5 which
// currently operates summer time or UTC +6 which currently operates the
// standard time.
// Right? (Question #2)
DateTimeOffset utcPublicationDateTime =
new DateTimeOffset(Publication_Utc_Date_Time_From_DataBase,
TimeSpan.Zero); // get an instance of type DateTimeOffset for the
// date and time of publication for further calculations
DateTimeOffset publication_DateTime_In_User_Local_DateTime =
utcPublicationDateTime.ToOffset(new TimeSpan(0, - userTimezoneOffset, 0));
return publication_DateTime_In_User_Local_DateTime.DateTime;// return to user
}
Is the value obtained correct? Is this the right approach to solving this problem? (Question #3)
UPDATED Oct 19 at 6:58 (I tried post it as a comment but it's too long by 668 characters)
Matt Johnson, Thank You for such a detailed answer despite that of the fact that you are doing this not the first time. Thank you for taking the time to explain this particular case, and not just provide links to other posts.
I have read the information that you have provided. Maybe I'm still not fully aware of all the details, but if I understand it right, for the right convertion of DateTime (which was written many years ago in the database) from UTC to the same user's moment, I need to know UTC offset which he had at that moment. And it is difficult taking into account that transfer rules for DST change constantly. And even now, though the platform ".NET" contains some TZDB that is used for the TimeZoneInfo type, I can't take advantage of it without the exact position of the user.
But what if I am only interested in the date and time of starting this year, and only in Russia, where DST was canceled in 2011? As I understand it, this means that if properly configured clock on user's computer, located in Russia, this approach will always give the correct result. And since 2011, the offset to UTC of user's clock should always be the same. Accordingly, the shift indicators in different browsers will not be different for the Russian user's.
Answer to Question 1
... does DateTimeOffset.UtcNow always returns the correct UTC date and time, regardless of whether the server is dependent on daylight savings time?
Yes. As long is your clock is set correctly, UtcNow always refers to the UTC time. The time zone settings of the server will not affect it. The value in your example will always be 4 minutes, regardless of DST.
Answer to Question 2
var offset = new Date().getTimezoneOffset();
Since new Date() returns the current date and time, this will return you the current offset. You then proceed to apply this current offset to some past value, which may or may not be the correct offset for that specific time. Please read the timezone tag wiki, especially the section titled "Time Zone != Offset".
Answer to Question 3
Is the value obtained correct? Is this the right approach to solving this problem?
No. This is not the correct approach. You have a few options:
First Option
Just pass the UTC value to JavaScript without modification.
Send it in ISO8601 format, such as 2013-10-18T12:34:56.000Z. You can get this in .Net easily using yourDateTime.ToString("o").
Be sure the DateTime you are starting with has .Kind == DateTimeKind.Utc, otherwise it won't get the Z on the end, which is essential.
If you are targeting older browsers that can't parse ISO8601, then you will need a library such as moment.js to parse it for you.
Alternatively, you could pass the number of milliseconds since 1/1/1970 UTC as a number and load that into a JavaScript Date instead of parsing.
Now you can just display the Date object using JavaScript. Let the browser convert it from UTC to the users local time.
Warning, with this approach, some conversions might be incorrect due to the problem I describe here.
Second Option
Like the first option, pass the UTC timestamp to JavaScript
Use that to get the offset for that timestamp.
Pass the offset back to the server in a postback or ajax call.
Apply the offset on the server
Output the local time zone
I don't particularly like this option because of the round trip. You might as well calculate it in JavaScript like the first option.
Third Option
Get the user's time zone. The best way is to ask them for it, usually on a user setting page.
Use it to convert from the UTC time to their local time completely on the server.
You can use Windows time zones and the TimeZoneInfo class to do the conversions.
Or you can use IANA/Olson time zones and the Noda Time library.
If you do this, you can optionally use a map-based timezone picker.
You can take a guess at the user's time zone with jsTimeZoneDetect.
This approach is more accurate, but requires more user interaction.
Also, please in future posts, ask just one question at a time. And please search before you post - I've written most of this in one form or another many times before.

Is there any case where DateTimeOffset might not be reliable?

I understand that to refer a single point in time DateTimeOffset is better and more reliable way compared to DateTime as it replaces .Kind property by a more convenient thing that is the Offset to UTC.
Does this solve all the issues regarding to storing a single point in Date-Time or are there still some cases that I should be concerned about?
(If there are can you give me examples where DateTimeOffset can't be reliable?)
Thanks
Given a DateTimeOffset, there is never any confusion about what point in time that represents. So they are always reliable.
But there are some cases where a DateTimeOffset alone is still not sufficient. Here's an example of a common situation:
You are in New York, USA on March 10th 2013.
You find out about an event happening at 1:00 AM local time.
You record it as a DateTimeOffset with the value 2013-03-10T01:00:00-05:00.
Later, you find out that you were given incorrect information, the event actually occurred at 3:00 AM.
So you go to edit, and you change the value to 2013-03-10T03:00:00-05:00.
But this would be incorrect. On that particular day, daylight saving time starts, and so 3:00 AM is only one hour later than 1:00 AM. If you just advance the time, without considering that the offset may have changed, then you am referencing the wrong point in time.
It should have been 2013-03-10T03:00:00-04:00.
To overcome this situation, you must also know that the time was recorded in New York. You knew that in the first step, but then it was thrown out when you recorded it. Somewhere else in your application, you must hold on to this fact. Preferably, you would keep a time zone id, so that you could re-calculate the correct offset.
If using the TimeZoneInfo class in your application, then you would want to track the value of the .Id property, along with your DateTimeOffset. For New York, the time zone id would be "Eastern Standard Time". This is a bit confusing, because this same value is used regardless of whether DST is in effect or not. (There is no Windows time zone with an Id of "Eastern Daylight Time"). Also, there is no built-in class or struct that will pair a TimeZoneInfo with a DateTimeOffset. You have to do it yourself.
If you are using Noda Time (which I highly recommend). Then you can take advantage of the IANA time zone id of "America/New_York", and the ZonedDateTime object - which is designed for this exact situation.
You should also refer to DateTime vs DateTimeOffset. You should find the analogy there quite useful.
There are also some cases where DateTimeOffset is not appropriate. Maybe this one is obvious, but it's still worth mentioning.
When you are not refering to a single moment in time, but a relative point on the calendar.
This happens more often than you would think. For example:
In the United States, this year daylight saving time began on March 10th 2013 at 2:00 AM.
But it didn't happen at at the exact same moment. Each time zone has their own local 2:00 AM, so there are actually several different transition points on the instantaneous timeline.
(Aside, but worth mentioning, in Europe, DST ("Summer Time") happens all at once. The transition is based on the same UTC moment for Western, Central, and Eastern European time.)
There are other real-world examples where the same point on the calendar is not the same point in time, yet people tend to think of them as if they were.
Day boundaries ("today", "yesterday", "tomorrow")
Other whole named days ("this Wednesday", "last Friday")
Television Shows ("7PM Tuesday nights")
Telephone Calling Plans ("Free nights and weekends")
Countless others...
In Noda Time, you would use a LocalDateTime for these scenarios. Without Noda Time, you would use a DateTime with .Kind == Unspecified.

Storing date/times as UTC in database

I am storing date/times in the database as UTC and computing them inside my application back to local time based on the specific timezone. Say for example I have the following date/time:
01/04/2010 00:00
Say it is for a country e.g. UK which observes DST (Daylight Savings Time) and at this particular time we are in daylight savings. When I convert this date to UTC and store it in the database it is actually stored as:
31/03/2010 23:00
As the date would be adjusted -1 hours for DST. This works fine when your observing DST at time of submission. However, what happens when the clock is adjusted back? When I pull that date from the database and convert it to local time that particular datetime would be seen as 31/03/2010 23:00 when in reality it was processed as 01/04/2010 00:00.
Correct me if I am wrong but isn't this a bit of a flaw when storing times as UTC?
Example of Timezone conversion
Basically what I am doing is storing the date/times of when information is being submitted to my system in order to allow users to do a range report. Here is how I am storing the date/times:
public DateTime LocalDateTime(string timeZoneId)
{
var tzi = TimeZoneInfo.FindSystemTimeZoneById(timeZoneId);
return TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, tzi).ToUniversalTime().ToLocalTime();
}
Storing as UTC:
var localDateTime = LocalDateTime("AUS Eastern Standard Time");
WriteToDB(localDateTime.ToUniversalTime());
You don't adjust the date for DST changes based on whether you're currently observing them - you adjust it based on whether DST is observed at the instant you're describing. So in the case of January, you wouldn't apply the adjustment.
There is a problem, however - some local times are ambiguous. For example, 1:30am on October 31st 2010 in the UK can either represent UTC 01:30 or UTC 02:30, because the clocks go back from 2am to 1am. You can get from any instant represented in UTC to the local time which would be displayed at that instant, but the operation isn't reversible.
Likewise it's very possible for you to have a local time which never occurs - 1:30am on March 28th 2010 didn't happen in the UK, for example - because at 1am the clocks jumped forward to 2am.
The long and the short of it is that if you're trying to represent an instant in time, you can use UTC and get an unambiguous representation. If you're trying to represent a time in a particular time zone, you'll need the time zone itself (e.g. Europe/London) and either the UTC representation of the instant or the local date and time with the offset at that particular time (to disambiguate around DST transitions). Another alternative is to only store UTC and the offset from it; that allows you to tell the local time at that instant, but it means you can't predict what the local time would be a minute later, as you don't really know the time zone. (This is what DateTimeOffset stores, basically.)
We're hoping to make this reasonably easy to handle in Noda Time, but you'll still need to be aware of it as a possibility.
EDIT:
The code you've shown is incorrect. Here's why. I've changed the structure of the code to make it easier to see, but you'll see it's performing the same calls.
var tzi = TimeZoneInfo.FindSystemTimeZoneById("AUS Eastern Standard Time");
var aussieTime = TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, tzi);
var serverLocalTime = aussieTime.ToLocalTime();
var utcTime = serverLocalTime.ToUniversalTime();
So, let's think about right now - which is 13:38 in my local time (UTC+1, in London), 12:38 UTC, 22:39 in Sydney.
Your code will give:
aussieTime = 22:39 (correct)
serverLocalTime = 23:39 (*not* correct)
utcTime = 22:39 (*not* correct)
You should not call ToLocalTime on the result of TimeZoneInfo.ConvertTimeFromUtc - it will assume that it's being called on a UTC DateTime (unless it's actually got a kind of DateTimeKind.Local, which it won't in this case).
So if you're accurately saving 22:39 in this case, you aren't accurately saving the current time in UTC.
It's good that you are attempting to store the dates and times as UTC. It is generally best and easiest to think of UTC as the actual date and time and local times are just pseudonyms for that. And UTC is absolutely critical if you need to do any math on the date/time values to get timespans. I generally manipulate dates internally as UTC, and only convert to local time when displaying the value to the user (if it's necessary).
The bug that you are experiencing is that you are incorrectly assigning the local time zone to the date/time values. In January in the UK it is incorrect to interpret a local time as being in a Summertime time zone. You should use the time zone that was in effect at the time and location that the time value represents.
Translating the time back for display depends entirely on the requirements of the system. You could either display the times as the user's local time or as the source time for the data. But either way, Daylight Saving/Summertime adjustments should be applied appropriately for the target time zone and time.
You could work around this by also storing the particular offset used when converting to UTC. In your example, you'd store the date as something like
31/12/2009 23:00 +0100
When displaying this to the user, you can use that same offset to convert, or their current local offset, as you choose.
This approach also comes with its own problems. Time is a messy thing.
The TimeZoneInfo.ConvertTimeFromUtc() method will solve your problem:
using System;
class Program {
static void Main(string[] args) {
DateTime dt1 = new DateTime(2009, 12, 31, 23, 0, 0, DateTimeKind.Utc);
TimeZoneInfo tz = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");
Console.WriteLine(TimeZoneInfo.ConvertTimeFromUtc(dt1, tz));
DateTime dt2 = new DateTime(2010, 4, 1, 23, 0, 0, DateTimeKind.Utc);
Console.WriteLine(TimeZoneInfo.ConvertTimeFromUtc(dt2, tz));
Console.ReadLine();
}
}
Output:
12/31/2009 11:00:00 PM
4/2/2010 12:00:00 AM
You'll need .NET 3.5 or better and run on an operating system that keeps historical daylight saving time changes (Vista, Win7 or Win2008).
Correct me if I am wrong but isn't
this a bit of a flaw when storing
times as UTC?
Yes it is. Also, days of the adjustment will have either 23 or 25 hours so the idiom of the prior day at the same time being local time - 24 hours is wrong 2 days a year.
The fix is picking one standard and sticking with it. Storing dates as UTC and displaying as local is pretty standard. Just don't use a shortcut of doing calculations local (+- somthing) = new time and you are OK.
This is a huge flaw but it isn't a flaw of storing times in UTC (because that is the only reasonable thing to do -- storing local times is always a disaster). This is a flaw is the concept of daylight savings time.
The real problem is that the time zone information changes. The DST rules are dynamic and historic. They time when DST starting in USA in 2010 is not the same when it started in 2000. Until recently Windows did not even contain this historic data, so it was essentially impossible to do things correctly. You had to use the tz database to get it right. Now I just googled it and it appears that .NET 3.5 and Vista (I assume Windows 2008 too) has done some improvement and the System.TimeZoneInfo actually handles historic data. Take a look at this.
But basically DST must go.

Categories