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.
Related
I have a request to alter current columns which are type of 'time' and instead of capturing just time I need to capture so called "utc time".
My idea is to create a fixed codelist with all timezones, and then to reference it to a appropriate table as FK.
My questions are:
Can column of a type 'time' hold also an information regarding time zones (utc, for example 15:00:00 +2 (gmt + 2)) and if not, could you suggest me another type for that column?
Should I maybe need to separate it into two columns? For example: [15:00:00] - StartTime, [+2:00] - UtcOffset
EF Insert: When I do inserting to the db, for that particular column, should I convert my DateTime object to for example DateTimeOffset?
Thanks in advance.
From the comments in your question, it sounds like you are building an appointment scheduling system. I'll base my answer on that, because your specific questions aren't quite aligned to the scenario you described.
First, it's important to understand that the relationship between a time zone and an offset is a one-to-many relationship. One time zone can have multiple offsets. In other words, a time zone is not an offset, but rather a time zone has an offset.
A time zone represents a geographic region where the local time is the same throughout. It is identified by a string ID, such as "America/Los_Angeles" (an IANA time zone ID) or "Pacific Standard Time" (a Windows time zone ID). In .NET, you will use them on the TimeZoneInfo object with the Id instance property or methods like FindSystemTimeZonesById.
An offset is like -07:00 or +05:30 or even +13:45. Any given offset applies only at a particular date and time. For example, in America/Los_Angeles, either -08:00 or -07:00 apply depending on whether daylight saving time is in effect at a given point in time. Keep in mind that DST is not the only reason for offsets to be different - many time zones have changed their standard time at some point in their history.
Also, it's called an offset because it is deviated from UTC by a certain amount. UTC itself always has a zero offset, delineated either by +00:00 or sometimes by Z. It's similar to GMT, except in how it is defined. UTC applies universally, everywhere. GMT technically applies only on the prime meridian. They both refer to the zero offset. You should prefer to say "UTC" in most cases.
Next, you should separate your application logic between future scheduling and present/past record keeping.
Present/past is the easier of the two. Since the moment in time has actually occurred, the local time and its offset from UTC is fixed forever. You can either store the local time and its offset in a single .NET DateTimeOffset structure (mapped to a datetimeoffset field in SQL Server). In other words, you can simply store 2021-07-27T12:00:00-08:00.
Note that you could instead store the equivalent UTC date and time, which would be 2021-07-27T20:00:00+00:00. However you've then lost the local time, and thus would need to convert back using the original time zone if you wanted to see that time. Some people prefer that, but I think it's more useful to store the original value.
For future scheduling, the situation is a bit different. Consider that the offset might not be the same for one appointment as it will be for the next appointment in the same time zone. Also consider that the definitions for which offset apply might change in between the time you schedule the appointment and when it comes around. (The likelihood of that increases the further out you schedule.)
Thus, for each location you should not store an offset, but rather a time zone identifier. Add a TimeZoneId to your object that stores each location (or each appointment depending on your model schema). Use TimeZoneInfo.GetSystemTimeZones to list the available time zones. The DisplayName property can be shown to your user, and the selected Id property gets assigned to the TimeZoneId.
Next you have to consider if you are scheduling a single appointment or creating a recurring appointment pattern.
For a single appointment you simply need the local date and time for that appointment. You can use a .NET DateTime struct (use datetime2 in SQL). Don't apply an offset, and don't convert to UTC. Just store the information provided.
For recurring appointments, you need to think through the information provided and store exactly what is given. For example, if the appointment is at 10:00 every other Tuesday, you'll need to store "10:00", "Tuesdays" and "2 week intervals". The data types for each will vary depending on how you choose to store and apply them. For example, you might use a time type for 10:00, but you could store the other values using integers. Appointments of different patterns could get stored in different ways.
Alternatively, some like to store patterns using a string containing a CRON expression. You can google that for more details.
Now you have everything you need to both schedule an appointment and record that appointment after it happens. But there's one part missing - you'll likely want some table of upcoming appointments that are easily queryable. For that, you've got a few options:
You can create a separate table via a background job of some kind. Periodically it would query all the appointments, use their information to compute the next upcoming appointment time, and insert it. You can store that in a DateTimeOffset, either as local time or as UTC. (SQL Server will always compute indexes on the equivalent UTC time either way.)
You could just add another field to your appointments that shows the next actual appointment time. You can then compute the next upcoming appointment whenever the appointment is created or updated, or when that appointment occurs, and update the table accordingly.
With either approach keep in mind that you will want to periodically check for time zone data updates (either via Windows Update or keeping the tzdata package current on Linux). You will also want to periodically re-compute future appointment times, in case that time zone data has been modified in a way that affects the appointments.
If all of this sounds super complicated - sorry, but it is. Doing scheduling worldwide across time zones right is challenging. If you want it simpler, you might want to look into a pre-made solution such as Quartz.NET, which you can integrate into your application.
I am making a world clock QML program. I am currently using an API to get the timezone ID of a certain city.
So for instance, for Delft, it would return
TimezoneID = Europe/Amsterdam
I store the city name and its timezoneID in a local sql database so that I wouldn't have to keep parsing online for the timezone info.
In my application, I have a ListView which displays the cityname along side its local time. How do I calculate the time at Delft using my system time and its timezoneID?
As far as I know, QML itself does not have this functionality, here are alternatives:
Since you already use a database, why don't you simply add the zone.tab part of the tz database to your database and calculate the times yourself? (Don't forget about daylight saving time...)
If you don't like that, you can also use TimezoneJS, a javascript library for handling timezones (which needs a copy of the same database mentioned above).
Or you write a C++ plugin for QML that encapsulatesdate and tzset.
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 have an application where all the DateTime's are always the time of the server. That means one time zone. The idea is to make the application compatible all over the world. The first step is to convert all the stored DateTime's in the database to UTC, that's no problem. Second step is to assume a timezone for the user (based out business logic), and to use as a default for displaying and parsing user input. Furthermore it would be nice if methods like DateTime.Now and other method calls that construct datetimes without explicit time zone/region information would also assume this time zone/region.
The idea is to assume a time zone for a user from the database. I have the user and his time zone, thats's no problem.
The problem is the presentation logic. There are DateTime.now methods all over the code, to convert all these methods is a lot of work.
To avoid that I need a global time zone setting where the DateTime knows which time zone it is. Preferably on a generic place.
class business logic
InitializeCulture()
set time zone for user
end function
end class
class presentation logic
sample()
TimeOfTheCurrentUser = DateTime.now
end function
end class
If you are looking for best practice for time zone handling in (more or less) enterprise application, I can share the proven one:
Store all date and time related information in UTC. Storing it as local time (on server or wherever else) always brings a risk that somebody, somewhere, someday forget to convert them and the results would be less than ideal. Of course it means that dates and times should be instantiated via DateTime.UtcNow or with proper DateTimeKind selected (this refers to parsing as well).
Obviously you need to convert time zone before displaying DateTime to end user. And you surely realize that you need to obtain this information from some source (thus the question). That somewhere could be client-side (which would work especially well with thick client and not so well with thin client's JavaScript) but could be just as well the user profile. If your application has user profiles, I would definitely recommend to allow user to select preferred time zone. Other g11n-related settings would be preferred culture for e-mails or preferred language. All of these settings should be detected and preselected (so the user does not have to think or more importantly click too much).
To convert DateTime classes to local time in another time zone, you would use TimeZoneInfo class. There are several ways to do that...
If you would implement this method, you may hit the problem with time zone names - they are in server's culture, so you would need to externalize (move to resource file) what TimeZoneInfo's DisplayName shows you and let translators do their jobs.
Also just a quick word what I meant by detect time zone.
On thick client you would do that by simply reading local time zone:
TimeZoneInfo currentTimeZone = TimeZoneInfo.Local;
With JavaScript (thin client) it is not that easy. The only thing you can get is a time zone offset (which could vary depending on date & time) on given date:
var date = new Date();
var offset = date.getTimezoneOffset(); // GMT offset in minutes
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.