I have my server in US and my client is in India, the problem is when he is inserting data there is a autoDate inside MSSql Table, but as the server is in different time zone, We are getting date with 12Hours different, how to overcome it.
Date in Table is AutoDate GetDate()
Regards
Use of UTC format may solve your issue. Please refer to these links
Convert UTC/GMT time to local time
How to handle conversion of a DateTime independently of the timezone of the hosting server?
How about changing your default constraint and rely on GETUTCDATE() instead of GETDATE()? This would solve your issue from the storage perspective.
You'd have to slightly alter your html rendering as well, in order to generate the date in a user friendly format, taking into account the user's timezone.
Related
I have a react app which uses firebase cloud functions. On the client side, I use pure javascript Date.now() to get the local time (PST timezone) of the client.
On server size, I also try to use the same approach to get the timestamp, but it is in different timezone. This will introduce an issue that if PST time is 8:15pm 12/07/2019, it will be 4:15am 12/08/2019, the date is different.
In this case, how can I keep the timestamp consistent between client and server side? Thanks!
There is no timezone data encoded into javascript Date objects or Firestore Timestamp object. Date objects represent time in terms of unix epoch time, which represents a specific point in time for all people on the planet. (Definitely learn what that is if you don't already.)
What you're likely doing is printing a string representation of the date, and it's being formatted the host's configured timezone. Since you haven't shown any code, it's impossible to say for sure, but it's a fact that Dates don't have a timezone.
If you want to format a date with a specific timezone, you should use a date formatting library that lets you specify which timezone should be represented in the string format.
I want to fetch date and time, in different timezone using SQLITE. Say, I get the value as, 20160118T010856 in input, but I require it to change to Australian, England and other timezone.
What I am currently able to do is :
select datetime('2016-01-18T04:13:39','localtime');
Which only provides me for my current local time. Kindly help.
As far as I know this is not possible in sqlite. Your best bet is to store the datetime as UTC and do the conversion outside the database.
From the documentation you could apply an offset(modifier) to a date and time, but it doesn't take Daylight Savings Time into account.
I have an existing web application with 70+ projects; DB: 700+ tables, 500+ stored procedures.
Currently there are many tables with Datetime/Date fields.
When saving date/datetime information in DB, i need to change them to UTC to support multiple time zone (since the application is going to be accessed across many regions - servers can also be hosted on multiple regions; currently it is accessed only from one region)
In order to do this i have come up with the below steps:
Get the list of tables with date/datetime field.
Check how its date time field is populated (ie. either through the application or through the procedure)
List item.
convert the datetime to UTC before saving it to DB.
When displaying it in the user's browser, convert the time back to the user's timezone.
Can write a query to update existing values with UTC.
The problem is the application by itself is very huge and there are too many places (both from the application & procedure) where datetime is updated; Though i can get the list of tables/procedure names through query directly, updating each procedure (in back end) /file (in front end) is a very tedious process
I would like to know the best approach/suggestions (change the application to support multiple timezone with minimal changes) to proceed in this situation.
Thanks!
The ideal situation is that all dates are UTC, in the stored procedures, in process code, in API interfaces etc.
The only time it should not be UTC is directly before it is rendered for a human user
As you indicate a web application, this should be isolatable to just the HTML rendering areas, and this should be the only code you need to change after you switch the DB to UTC
You should just need two function changes:
Decode human input into a valid date and convert into UTC from that sessions time zone (do this before any other processing logic)
Convert date value from UTC to current sessions time zone, and format into human readable form (do this just before displaying date)
These two functions should already exist in your UI code for date formatting and validation, they just need tweeking
It's too late for you, but when designing an application which puts a datestamp on any record changes, the correct thing to do is to write a SQL trigger that sets the date appropriately.
We have an ASP.NET website and an SQL database hosted in US. Whenever I use the function Now() in VB.NET and getdate() in SQL, I get the US' current time. The problem is, the client is in the Philippines which is on GMT+8 Time Zone. My question is, is there any way I can set the Time Zone of a specific database and website so that when I use the functions, I'll get the Philippine's current time? How do you deal with this? As much as possible, we don't want to do subtraction or addition to the result date of the functions since in the future, clients will be from other country. It will give us headache updating the codes if we do that.
Thank you in advance!
Given that your clients may be in different time zones, you should store a timezone for the clients, that they (or you) can set as a preference for their account. Store all dates+times as UTC, and then convert to their timezone when displaying results in your interface.
This question has already been addressed to a great extent in the following question:
How to work with time zones in ASP.NET?
Follow-up:
Unfortunately, the SQL server date is a system-level setting, so it's not really something that can be manipulated on a per-session basis. It sounds like you will need to make some code changes, but you can isolate them.
Do you have a session-level variable which contains the client time zone offset? If not, create one.
Create a small date/time utility class.
In the utility class, provide 3 methods to:
(1) get the current date/time (offset to the client's time zone)
(2) pass in a database date/time to return the time offset for the client's TZ.
(3) pass in a time from the client to subtract out the client's TZ difference.
You will have to make code changes, but you can probably use those utility functions to wrap inputs and outputs everywhere, centralizing the logic. Microsoft has a page about mis-steps to avoid when using the DateTime class and manipulating time zones:
http://msdn.microsoft.com/en-us/library/ms973825.aspx#datetime_topic1a
I am working on cleaning up a bug in a large code base where no one was paying attention to local time vs. UTC time.
What we want is a way of globally ignoring time zone information on DateTime objects sent to and from our ASP.NET web services. I've got a solution for retrieve operations. Data is only returned in datasets, and I can look for DateTime columns and set the DateTimeMode to Unspecified. That solves my problem for all data passed back and forth inside a data set.
However DateTime objects are also often passed directly as parameters to the web methods. I'd like to strip off any incoming time zone information. Rather than searching through our client code and using DateTime.SpecifyKind(..) to set all DateTime vars to Undefined, I'd like to do some sort of global ASP.NET override to monitor incoming parameters and strip out the time zone information.
Is such a thing possible? Or is there another easier way to do what I want to do?
Just to reiterate -- I don't care about time zones, everyone is in the same time zone. But a couple of users have machines badly configured, wrong time zones, etc. So when they send in July 1, 2008, I'm getting June 30, 2008 22:00:00 on the server side where it's automatically converting it from their local time to the server's local time.
Update: One other possibility would be if it were possible to make a change on the client side .NET code to alter the way DateTime objects with Kind 'Undefined' are serialized.
I have dealt with this often in many applications, services, and on different platforms (.NET, Java, etc.). Please believe me that you do NOT want the long term consequences of pretending that you don't care about the time zone. After chasing lots of errors that are enormously difficult and expensive to fix, you will wish you had cared.
So, rather than stripping the time zone, you should either capture the correct time zone or force a specific time zone. If you reasonably can, get the various data sources fixed to provide a correct time zone. If they are out of your control, then force them either to the server's local time zone or to UTC.
The general industry convention is to force everything to UTC, and to set all production hardware clocks to UTC (that means servers, network devices like routers, etc.). Then you should translate to/from the user's local time zone in the UI.
If you fix it correctly now, it can be easy and cheap. If you intentionally break it further because you think that will be cheaper, then you will have no excuses later when you have to untangle the awful mess.
Note that this is similar to the common issue with Strings: there is not such thing as plain text (a String devoid of a character encoding) and there is no such thing as a plain (no time zone) time/date. Pretending otherwise is the source of much pain and heartache, and embarrassing errors.
OK, I do have a workaround for this, which depends on the fact that I only actually need the Date portion of the DateTime. I attach this property to every Date or DateTime parameter in the system
<XmlElement(DataType:="date")>
This changes the generated wsdl to have the type s:date instead of s:dateTime. (Note that simply having the type of the .NET method parameter be a Date rather than a DateTime did NOT accomplish this). So the client now only sends the date portion of the DateTime, no time info, no time zone info.
If I ever need to send a Date and Time value to the server, I'll have to use some other workaround, like making it a string parameter.
I've had issues with the time zone information as well. The problem is I'm already providing the datetime fields in UTC. Then the serialization occurs and the local offset becomes part of the date/time. The dates/times for our vendor in a different timezone were pretty messed up. I got around this problem by using the tsql convert function on the datetime fields in my select statement I used to populate my datasets. This converted the fields to a string variable, which translates nicely to a datetime value automatically on the client side. If you just want to pass the date, you can use the 101 code to provide just the date. I used 126 to provide the date and time exactly how it appears in my database columns, with the timezone information stripped out.