I have encountered a weird problem with asp.net profiles which is about the value in LastUpdatedDate column in aspnet_Porfile table of asp.net profiles and membership tables.
I am in a country with currently one hour daylight saving. The current time of my local machine is one hour behind what gets saved in the above column and I am totally working locally so there is no database or web server datetime coming through.
Have someone else experienced the same issue with asp.net profiles? It seems it ignores daylight saving settings.
Most ASP.NET 'extras' use UTC which is not affected by DST.
Datetime.ToLocalTime should do the conversion depending on how you create the Datetime you get from the DB
Related
I thought this was the correct way to do this, but apparently it is not.
I write a date to an SQL Server database using the default of GetUtcDate().
I read it back in ASP.NET and display it to the user with theTime.ToLocalTime().
(It's already in UTC, so I need to convert it to localtime, NOT into UTC time again.)
Wouldn't that make the date/time display correctly any where in the world?
But it seems to be 1 hour off when:
The SQL Server is in 1 time zone (might be... or not be in a DST area or time of year).
The webserver running the ASP.NET is in a different timezone (it also may or may not be DST there).
The local user viewing the date/time is also in a totally different timezone (also with or without DST there).
(I'm not sure if it matters, but the webserver only has .net v1.1 and will NEVER be upgraded to v2 or anything else.)
Storing UTC values using GETUTCDATE is fine. Retrieving UTC values into a DateTime object on your web server is fine also. Calling ToLocalTime is not.
When you use ToLocalTime, you are using the local time zone of the machine where the code is running. In this case - your web server.
The web server has absolutely no knowledge of the timezone of your user. You have to manage that yourself in your application logic. Since you are stuck on .Net 1.1, you have no easy way to manage this server side. You'll have to take a client-side JavaScript approach:
Pass the UTC value to the client in a non-displaying manner. For example, an XHR call, or inline script.
Preferably, use the ISO-8601 format, such as 2014-06-10T09:30:00.000Z. You can get this from your DateTime object by using .ToString("o").
On the client, if you're using newer web browsers, you can pass this string directly into the constructor of a JavaScript Date object. However, you may prefer to use a more robust library for browser compatibility and enhanced formatting capabilities. I recommend moment.js.
By passing the UTC value to the browser, you've delegated the work of figuring out the user's time zone. Calling any of the output methods on the Date or moment objects will show the time converted to the user's time zone automatically.
There are plenty of server-side approaches, but they would require you update to a more reasonable version of the .NET Framework.
TimeZoneInfo and Noda Time work on .NET 3.5 and greater.
TZ4Net works on .NET 2.0
With any of the server-side mechanisms, you would need to change your application to:
Ask the user for their time zone in some settings part of your application.
Apply that time zone to the UTC date before delivering a string to the web browser.
Also, you should recognize that .NET 1.1 was released in 2003, and is way past its lifecycle end date. You should review the chart here and consider upgrading.
I have an Azure website that have datetime set to GMT + 0. All of my users are located in GMT +2.
Is there a simple way how to set the time offset globaly on application startup so all the DateTime values will be rendered with the correct offset?
It depends on what your programming language provides. For example, in PHP, you can use date_default_timezone_set. However, in .NET and many other languages, there is no way to change the default time zone - it will always use the local time zone of the machine it's running on.
It's good that Azure sets it's time zones to UTC. It's really not good for a server application or web site to depend on the time zone settings of the computer it's running on. You should simply rely on the features of the language to write your application such that you are in control of the time zone functionality. For example, in .Net, you can use TimeZoneInfo to convert times to any time zone you wish.
Have you tried DateTime.ToLocalTime?
I am working on an application whose targeted audience is located throughout the globe. My development platform is ASP.Net/Sql Server both are currently hosted on same dediacated server at present.
There could be possibility that Sql Server may be moved into different server and web application to be hosted on different server. Time zone may be different for both the servers.
Currently we are into development and need to handle Universal Date time concept rather than fighting at later stages.
Our database currently is structured with following type of columns for datetime.
DateTime(mm/dd/yyyy hh:MM:ss), SmallDateTime(holds date part only mm/dd/yyyy 12:00:00), Varchar(holds hhMMss in 24 hour format only)
Currently we are saving GetDate() of Sql Server, DateTime.Now of C# i.e. ASP.NET, javascript datetime and any other date directly. No UTC conversion or nothing like that is applicable at the moment. We are neither storing any TimeZone or any offset at the moment.
How do I handle DateTime related issues when
Calling Stored procedure to Save DateTime from UI to Database
Display data from Stored procedure to UI
Display data from ASP.NET Server to Client Browser
Save data from Client Browser to ASP.NET Server
Please suggest some code examples for each of the cases along with Daylight Saving
I work in the company that has business all over the world and we store all dates in UTC.
Basically, in your sql you have to use GETUTCDATE() function instead of GETDATE()
and in C# you use DateTime.UtcNow instead of DateTime.Now.
Database fields could be standard datetime
In your UI you can display date in yyyy/MM/dd format if you don't know or cannot figure out client's local settings.
Does ColdFusion 8 have any built-in support for handling timezones? We'd like our users to be able to choose a timezone and then have all dates/times on the site adjusted to their locale. Currently we're asking users to set an offset from server time, and it's a headache because they have to go in a couple times each year and manually adjust for daylight savings time.
We're running CF8 on Windows and all dates/times are stored in SQL Server 2005 in Pacific Time. So when Windows auto-adjusts the local clock between Daylight and Standard time, a certain number of our users need to adjust their offset from server time.
I've looked through the International Functions, and none of them seem to convert between timezones. We don't want to turn to a Web Service to get offset/daylight info if it's built into the JVM, and ideally we'd stick with CF functions if they're available. Seems like a common need so I'm surprised there's nothing built into CF to handle this. Is there?
GetTimeZoneInfo() will tell you if daylight saving time is currently in effect on the server, you could use this information along with a checkbox for DST when the user selects their server time offset.
Setup: Windows Server 2003 / SQL Server 2005. ASP.NET 2.0. IIS 6.
The site I'm working on uses ASP.NET Membership and when a user is created it is inserted into the aspnet_membership database.
All servers are set at Central Time. I also verified this by doing a Select GetDate() on SQL Server and it returned central time.
However, when a user is inserted into aspnet_membership, their CreateDate is listed in GMT. (Greenwich Mean).
I've looked at the code and there is NO DateTime.Now.AddHours(6); anywhere associated with creating members.
Does Membership just uses GMT by default? Can this be changed somewhere? Is there any advantage to using GMT? I'm not doing any Timezone specifics on the users side, so I see no need for it.
Anyway if you have any ideas on what I'm overlooking it would be greatly appreciated.
Thank you!
Membership does automatically use UTC as described in this article:
https://web.archive.org/web/20210309215647/http://aspnet.4guysfromrolla.com/articles/041608-1.aspx
Using UTC (not GMT) has the additional advantage that you don't have to worry about Daylight saving.
If you look at the dbo.aspnet_Membership_CreateUser stored procedure you find a #CurrentTimeUtc parameter, which suggets to me that all datetimes in the ASP.NET Membership are indeed UTC.
You can use the DateTime.ToLocalTime to convert to local (server) time.