I am logging time in many places
If Request.DynamicSettings.AirlineSettings.AirlineGeneralSettings.TimeLogEnabled Then
StartTime = DateTime.Now
LogTime(Reflection.MethodBase.GetCurrentMethod.DeclaringType.FullName, Reflection.MethodBase.GetCurrentMethod.Name, StartTime, DateTime.Now, "AB-SCR(I)", 0,)
End If
all places i have used
DateTime.Now
I am facing an issue now,
I am currently hosting this in a gulf server, GMT +4:00
I need to host this same project for another country at Gmt +3Gmt
for this hosting i need time to be logged using that country's local time.
Is there any way to do this, without having to modify each and every line of my code.
i have seen this article timzone with asp.net but as my service is already up i have a lot of codes to change, i am looking for a simpler solution.
thanks.
A few things:
You cannot change the time zone in the IIS configuration or web.config. This is not an IIS problem, but rather a problem in your application code.
DateTime.Now should never be used in a server side application, such as an ASP.Net web application. Read The case against DateTime.Now.
If you are just timing how long something takes to run, don't use DateTime at all. Instead, use System.Diagnostics.Stopwatch.
Stopwatch sw = Stopwatch.StartNew();
// ...do some work ...
sw.Stop();
TimeSpan elapsed = sw.Elapsed; // how long it took will be in the Elapsed property
If you actually want the current time in a specific time zone, then you need to know the time zone identifier. (GMT+4 and GMT+3 are not time zones, but rather time zone offsets see "Time Zone != Offset" in the timezone tag wiki.) You can see a list of Windows time zones by using TimeZoneInfo.GetSystemTimeZones(), or by calling tzutil /l on the command line.
Then in your application:
string tz = "Arabian Standard Time";
DateTime now = TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, tz);
You should probably refactor your code such that this is done inside your LogTime method. Then you will have only one place to set the time zone for your application.
Related
I have a c# desktop application that consumes an API. My Client is from a different time zone. So when we both consume the same API, we get different date time even the date is the same in the database. How can I set the default time zone for my application in c# code so that when I access it from the development environment, I can set my timezone and when I deploy it in production then I can set my client's time zone? I already debugged and found .NET automatically converts the time as soon as it gets the response from the API, so I can not do anything in the response stream.
if the dateTime is changing for you and your client, it means that there is an offset value attached to the dateTime when it is retrieved from the API.
So, do a check for development environment in your application and fetch the UTC DateTime using "UtcDateTime" property of DateTimeOffset type and display it in the UI so that it is the same for both you and your client. In case of the production environment, just keep the usual flowing going.
if(IsDevEnvironment)
DateTimeToDisplay = ApiResponse.DateTimeInDB.UtcDateTime; // assuming DateTimeInDB is of DateTimeOffset type
else
DateTimeToDisplay = ApiResponse.DateTimeInDB
Here is a way to set a timezone, example eastern timezone.
TimeZoneInfo easternZone;
try { easternZone = TimeZoneInfo.FindSystemTimeZoneById("E. Africa Standard Time"); }
catch (TimeZoneNotFoundException) { easternZone = TimeZoneInfo.FindSystemTimeZoneById("Africa/Nairobi"); }
var timestamp = TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, easternZone);
try that ;
HAVING (Time BETWEEN DATEADD(d, - 1, GETUTCDATE()) AND GETUTCDATE())
it is helpful for me.
example
ELECT Time, username, COUNT(username) AS CountOfusername
FROM dbo.tabl
GROUP BY Time, username
HAVING (Time BETWEEN DATEADD(d, - 1, GETUTCDATE()) AND GETUTCDATE())
edit
DateTime hwTime = TimeZoneInfo.ConvertTimeBySystemTimeZoneId(DateTime.UtcNow, "Arab Standard Time");
//DateTime hwTime = new DateTime();
try
{
TimeZoneInfo hwZone = TimeZoneInfo.FindSystemTimeZoneById("Arab Standard Time");
Console.WriteLine("{0} {1} is {2} local time.",
hwTime,
hwZone.IsDaylightSavingTime(hwTime) ? hwZone.DaylightName : hwZone.StandardName,
TimeZoneInfo.ConvertTime(hwTime, hwZone, TimeZoneInfo.Local));
}
catch (TimeZoneNotFoundException)
{
Console.WriteLine("The registry does not define the Arab Standard Time zone.");
}
catch (InvalidTimeZoneException)
{
Console.WriteLine("Registry data on the Arab Standard Time zone has been corrupted.");
}
us this code in your application
I have a .NET Core 2.2 web app running inside a docker-compose app. I'm saving different UTC time stamps to a database, like this:
//set asked state on question
Question questionInDb = c.Questions.Single(x => x.Id == id);
questionInDb.Asked = true;
questionInDb.AskTime = DateTime.UtcNow;
c.SaveChanges();
In the apppsettings.json I have a section for my app's settings, containing the locale the application is supposed to run on. I set the CultureInfo.CurrentCulture like so:
//get locale from settings, defaulting to de-DE
string locale = "de-DE";
locale = Configuration.GetValue<string>("AppSettings:Locale");
var ci = new CultureInfo(locale, false);
//actually setting locale
CultureInfo.CurrentCulture = ci;
I set up my Entity Framework to set all DateTimes to DateTimeKind.Utc, so the app knows the DateTimes it gets are all UTC.
Now, when displaying the time on a view, it's not the right hour. In the view.cshtml I'm using #q.AskTime.ToString("HH:mm:ss dd.MM.yy"), but it always returns the exact value from the database. It's supposed to show one hour more.
I even tried setting the container's timezone to CET (Centran Euopean Time) using ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone (in my docker-compose I set the environment variable TZ to Europe/Berlin).
I'm out of ideas.
Cultures (also known as locales) are used for displaying and formatting data and is a different concept than timezones. You can find and create a specific TimeZoneInfo from a timezone name and convert an UTC date and time using the ConvertTimeFromUtc() method.
Keep in mind that different operating systems use different timezone names. For example you can use Europe/Berlin for Linux and Central Europe Standard Time for Windows.
Example:
TimeZoneInfo tz;
try
{
// Linux
tz = TimeZoneInfo.FindSystemTimeZoneById("Europe/Berlin");
}
catch (TimeZoneNotFoundException)
{
try
{
// Windows
tz = TimeZoneInfo.FindSystemTimeZoneById("Central Europe Standard Time");
}
catch (TimeZoneNotFoundException)
{
// Fallback to UTC
tz = TimeZoneInfo.Utc;
}
}
var converted = tz.ConvertTimeFromUtc(DateTime.UtcNow);
I'm setting up a calendar invite email using ical.net. Sending out a non-recurring event seems to work perfectly: I set the start and end date like this
iCalEvent.DtStart = new CalDateTime(DateTime.SpecifyKind(model.EventTime.Value, DateTimeKind.Utc));
iCalEvent.DtEnd = new CalDateTime(DateTime.SpecifyKind(model.EventTime.Value.AddMinutes(model.DurationMins.Value), DateTimeKind.Utc));
when the email arrives, the time zone has been converted to the recipients timezone (The timezone is -7, the eventTime is 4pm and the duration is 3 hours)
However, when I take this same exact code and add this line to it
IRecurrencePattern recurrence = new RecurrencePattern(FrequencyType.Daily, 1)
{
Until = DateTime.SpecifyKind(model.endDate.Value.AddDays(1), DateTimeKind.Utc)
};
iCalEvent.RecurrenceRules = new List<IRecurrencePattern> { recurrence };
Suddenly my timezone is no longer converted when the email is received (The timezone is -7, the eventTime is 4pm and the duration is 3 hours. The endDate is on the 28th)
I need the DateTime to be displayed to the user in their own timezone and I need to display recurring events from the eventTime to the endDate
It may also be useful to note that I do not have a timezone property specified on Calendar as it was causing the sent email to show a "not supported calendar message" in outlook. Before I removed it, it looked like this
iCal.AddTimeZone(new VTimeZone("UTC"));
when I opened ical files that had this time zone specified, they seemed to work correctly for multi day events, but as I need them to appear in outlook with the accept/decline/tentative buttons, it is out of the question to add it back
i've also tried specifying datetimes like this
iCalEvent.DtStart = new CalDateTime(leEvent.EventTime.Value, "UTC");
but nothing changed
EDIT: I now understand that the issue is due to a recurring event needing a timezone as specified here, but I'm not quite sure where the timezone needs to be specified. I went back to adding the vTimeZone back in and validating it through this site, and it appears that the iCal file is missing the standard/daylight section inside of the timezone block
I have also tried specifying the timezone as GMT and specifying the timezone as "\"America/Phoenix\"" so that the tzid came out as TZID:"America/Phoenix" (with quotes in the ical file.
This is my code at the moment that causes the issue.
iCalEvent.DtStart = new CalDateTime(DateTime.SpecifyKind(model.EventTime.Value, DateTimeKind.Utc));
iCalEvent.DtEnd = new CalDateTime(iCalEvent.DtStart.Value.AddMinutes(model.DurationMins.Value));
if (model.EndDate.HasValue)
{
IRecurrencePattern recurrence = new RecurrencePattern(FrequencyType.Daily, 1)
{
Until = DateTime.SpecifyKind(model.MaxDate.Value, DateTimeKind.Utc).ToLocalTime()
};
iCalEvent.RecurrenceRules = new List<IRecurrencePattern> { recurrence };
iCalEvent.DtStart = new CalDateTime(iCalEvent.DtStart.Value.ToLocalTime(), "America/Phoenix");
iCalEvent.DtEnd = new CalDateTime(iCalEvent.DtEnd.Value.ToLocalTime(), "America/Phoenix");
iCal.AddTimeZone(new VTimeZone("America/Phoenix"));
}
I'm not quite sure what needs to happen to correct the standard/daylight ical error from this point.
FINAL EDIT:
after reading through this post, I found that this issue has already been solved as of last november. I checked the version we had in our project and it turned out some genius just copied the dll straight in without setting it up through nuget (and a version from several years ago no less). I grabbed the latest version and this time specifying the timezone caused no issues in outlook. I'm still experimenting with addTimeZone and addLocalTimeZone but I'm definitely on the right track. Thank you to rianjs for this extremely useful library. I don't know how I would possible work with this crazy calendar standard without it.
A recurring event is always relative to the sender's timezone (or rather to the event location), and not to the recipient's timezone, because of daylight saving changes which may happen at different time between the organiser and the various recipients.
So in most cases you want to use a meaningful timezone in the event (i.e. not UTC).
Then Outlook is simply showing that the event is indeed happening according to the given timezone. This is an indication that the event may not always be at the same time of day for the recipient.
Since this took me so long to figure out, I might as well share my solution in case anyone else runs into this problem and finds this.
I defined the DtStart/DtEnd with two datetimes that had kind utc
calendarEvent.DtStart = new CalDateTime(model.EventTime.Value);
calendarEvent.DtEnd = new CalDateTime(model.EventTime.Value.AddMinutes(model.DurationMins.Value));
which worked great for single day events, but with multidays I ended up doing this
if (model.EndDate.HasValue)
{
RecurrencePattern recurrence = new RecurrencePattern(FrequencyType.Daily, 1)
{
Until = model.EndDate.Value //has kind: Utc
};
var timezoneOffsetString = "Etc/GMT";
if (timezoneOffset > 0) //client time zone offset, calculated through js
{
timezoneOffsetString += "-" + timezoneOffset;
}
else if (timezoneOffset < 0)
{
timezoneOffsetString += "+" + (-1 * timezoneOffset);
}
calendar.AddTimeZone(timezoneOffsetString);
calendarEvent.DtStart = calendarEvent.DtStart.ToTimeZone(timezoneOffsetString);
calendarEvent.DtEnd = calendarEvent.DtEnd.ToTimeZone(timezoneOffsetString);
calendarEvent.RecurrenceRules = new List<RecurrencePattern> { recurrence };
}
It's not fullproof as some places may have weird dst problems, but nodatime was treating the "America/Phoenix" tzid as an LMT time, which was giving me a time that was like 28 minutes off... Besides, treating all dates as GMT is closer to the implementation we have in the rest of our app so it worked for my situation
This solution gave me the idea to piece together the Etc/GMT stuff.
I have screen in c# asp.net webapplication, where i add news on particular dates.And can edit those dates also.It workes in my local sytem.But shows datetime error when it was running in iis 7 server(Used sql database).And i knew that the short date and long date format in server was different from local system.So i changed date format in local system same as in iis.But still it is working properly.
Instead of guessing culture settings write code that sets one you need before reading from database/restore after unsing Thread.CurrentCulture property. Simialr to code below (need to also use CurrentUICulture, chose cuture you need and wrap code around setting/restoring into try/finally for real code)
var oldCulture = Thread.CurrentThread.CurrentCulture;
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
// read from DB
...
Thread.CurrentThread.CurrentCulture = oldCulture;
How can I get the Original Install Date of the Windows using C#?
From this website, using the registry rather than WMI (untested):
public static DateTime GetWindowsInstallationDateTime(string computerName)
{
Microsoft.Win32.RegistryKey key = Microsoft.Win32.RegistryKey.OpenRemoteBaseKey(Microsoft.Win32.RegistryHive.LocalMachine, computerName);
key = key.OpenSubKey(#"SOFTWARE\Microsoft\Windows NT\CurrentVersion", false);
if (key != null)
{
DateTime installDate =
DateTime.FromFileTimeUtc(
Convert.ToInt64(
key.GetValue("InstallDate").ToString()));
return installDate;
}
return DateTime.MinValue;
}
The HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate is the Windows InstallDate using a Unix timestamp, but technically it's the wrong date.
Let me explain;
The definition of UNIX timestamp is time zone independent. The UNIX timestamp is defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970 and not counting leap seconds.
In other words, if you have installed you computer in Seattle, WA and moved to New York,NY the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate will give you the date in NY timezone, not in Seattle timezone where Windows was original installed. It's the wrong date, it doesn't store timezone where the computer was initially installed.
Solution
Change you computer time zone (right-click on you clock->Adjust date/time->Adjust time zone) to the time zone where windows was installed, or first turned on. Then run systeminfo.exe find /i "Original Install Date"
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate but you have add the time zone where windows was installed, or first turned on.