Forms Authentication dates an hour behind

Can't figure out why these dates are wrong

[bhonda]

Hey guys,

Real quick question here, hopefully someone can point me in the right direction.

I've got a very simple ASP.NET 4 web application that implements forms authentication, using SQL Server as the membership provider.

Everything works perfectly, but I've just noticed that the internal dates in the Membership tables (LastLoginDate, LastPasswordChangedDate, etc) are an hour behind. For example, it's 12.27pm at the moment, but if I log in, the date updated will be 11.27am.

The clock on the server is correct, the SQL command getdate() returns the correct date, everything looks fine. I guess this is a daylight savings issue, but does anyone have any idea as to where the dates are getting mixed up?

Cheers,

B

[Ocean10000]

What is the time on the webserver? This is where the date and time will be recorded from usually.

[bhonda]

Hey,

The time on the server is correct. I would assume that's where the time is taken from too..but it just doesn't seem to be happening!

Cheers,

B

[g1smd]

You should be recording dates and times without DST otherwise when you change back to standard time your records will be out of sequence.

If you insist on using local "clock" time, then in October you will have two hours where you will run from 1 am to 2 am twice in a row.

Can your software really cope with someone doing something at 01:59 and then two minutes later doing something at 01:01?

Then, in reverse, next April you'll have an hour completely missing as you jump directly from 00:59:59 to 02:00:00.

Better yet, you should record all transactions in UTC date time. That's an unwavering timescale (apart from the odd leap-second several times per decade).

[bhonda]

Hey,

Thanks - that's the way I'd like to do it, but I've never configured anything to use DST, so I would assume (perhaps wrongly?) that it is the default to use UTC.

So, any idea which part of the process would be using DST? If not the server, or the database, or the client...where else could it come from?

Cheers,

B

[g1smd]

That's the point. If your time on the wall clock in your office is 2 p.m. DST then your Standard Time without DST applied is 1 p.m. Hopefully your server is using that standard time.

When you put your office clock back an hour in October from 01:59:59 to 01:00:00, hopefully you server will not jump back an hour but instead will roll over from 00:59:59 to 01:00:00 and then be in step with your office clock all through your winter.

Next spring as you put your office clock forward from 00:59:59 to 02:00:00 hopefully your server will roll on one second from 00:59:59 to 01:00:00 and be out of step by an hour all through the summer; i.e. your server hopefully runs on standard time all year round.

[bhonda]

Erm...I think that makes sense, but we're in British Summer Time at the moment, not Daylight Savings.

Still don't understand where this missing hour is going!

Cheers,

B

[g1smd]

- delete -

[edited by: g1smd at 5:00 pm (utc) on Jul 21, 2011]

[g1smd]

Daylight Savings Time is the American equivalent of British Summer Time.

The time right now is 17:00 UTC (UTC was known as GMT before 1972). Purists look away as that's not 100% technically correct but it will do for the situation here.

UK clocks are using BST from April to October. BST is UTC+0100. So, it is 18:00 BST now.

Hopefully your server runs on UTC all year round.

[bhonda]

Well we're a UK based organisation, and I don't think it makes sense to run in a different time zone to what we're in.

But, regardless of that, let's assume I can't change the timing of the server, and go back to the OP.

How can I get Forms Authentication to use the datetime that the server and database is using?

Cheers,

B

[LifeinAsia]

What is the time on the webserver?

Actually, it might be better to ask what the time is on your database server, as it depends on whether you are passing the date/time to the DB from the web server or the DB server is using its internal date/time.

We used to run into this problem all the time when our web servers were running Win2K and the DB servers were running on Win2003. The Win2003 servers were correctly patched for the U.S. Daylight Saving Time change, but the Win2K servers weren't (so they were automatically changing the time on the OLD change dates). We had a web-based time clock application (employees had to clock in and out for their work hours) that was using the web server time instead of the DB time.

In regards to the OP, I would check the configuration to see if there is a setting somewhere to offset the date by an hour.

[marcel]

ASP.NET Membership always stores the UTC time.

[g1smd]

ASP.NET Membership always stores the UTC time.

Great. That avoids a lot of problems.

[bhonda]

Ok, is there anyway to configure it?

[g1smd]

Configure it for what?

It is doing exactly what it is supposed to do; run on a constant time scale all year round.

That's the correct operation: match UK clock time in the Winter (when UK clocks run on UTC) and run one hour behind UK clock time in the Summer (when UK clocks are artificially advanced one hour onto the BST time zone offset).

[bhonda]

Sorry if I'm not making much sense here, but I have an application that stores dates in local time. Now that I'm using this Membership, I'd quite like it to store dates in the same format. Makes it a lot easier when doing comparisons and reporting.

To save me reformatting all the dates in all our applications, I'm asking is there any other alternative?

Even if the answer is no, I'd just like to know!

Cheers,

B

[g1smd]

stores dates in local time.

store dates in the same format.

By format, are you now talking about 20/07/2011 vs. 2011-07-20?

[bhonda]

Format as in local time, or daylight savings. I don't have a problem with dd-MMM-yyyy etc.

Sorry for my poor terminology, I'm getting tired and couldnt think of the term!

Cheers,

B

[marcel]

Ok, is there anyway to configure it?

You don't need to, Membership does it all for you. Don't query the Database yourself, just use the following code:

DateTime lastLogin = Membership.GetUser().LastLoginDate;

You'll see that .NET Membership automatically adjusts to the 'correct' time.

[bhonda]

You'll see that .NET Membership automatically adjusts to the 'correct' time.

You know, I was driving to work this morning, and this thought crossed my mind. I realise I never actually checked this! It's great to have some confirmation for it though!

I'll have a crack at this when I get started today - thanks!

Cheers,

B