I am trying to determine, how I should implement local time in a web-app. All users are logged in, there are no anonymous users. They will need to see all time-values in their local time.
Is this how it should be done?
All DateTime values are saved as UTC-time in database
Each user has a UTC-Offset value stored in his profile
When displaying a datetime-value, I take the value from the database, and apply the users offset.
Is this the way to go? Or am I missing something?
Don't store a UTC offset for the user - that's not enough to know the full time zone information. You should store their Olson time zone ID, e.g. "Europe/London". Then you can display any UTC time in the local time, taking into account historical changes, daylight savings etc.
EDIT: It looks like the TimeZoneInfo ID isn't actually in the normal Olson format - but so long as there's something sensible you can display to the user (as a choice), and an ID you can retrieve the zone from later on, that's probably okay... you may have difficulties if you need to interoperate with other systems later though.
You should ask the user for their time zone (possibly trying to guess it first through JavaScript) - they will have more information than you do.
You should investigate the TimeZoneInfo class for more on this - I can't say I've used it much myself, but it's the way to go as of .NET 3.5. In particular, FindSystemTimeZoneById and GetSystemTimeZones will be important.
Time zones are a pain in general, but at least TimeZoneInfo gives a lot more support than the old TimeZone type.
That sounds like the most straightforward way to me. The only slip ups I could see occurring are some areas (such as parts of Indiana and I think all of Arizona) don't cooperate with daylight savings time, so you'll have to take extra precautions displaying the correct time for them.
Related
I have a simple mobile app that schedules future events between people at a specified location. These events may be physical or virtual, so the time specified for the event may or may not be in the same timezone as the 'location' of the event. For example, a physical meeting may be scheduled for two people in London at local time 10am on a specified date. Alternatively, a Skype call may be scheduled for two people in different timezones at 4pm (in one person's timezone) on a specified date though the 'location' of the event is simply 'office' which means two different places in different timezones.
I wonder the following design is going to work for this application:
On the client, it asks user to input the local date and time and specify the timezone local to the event.
On the server, it converts the local date and time with the provided timezone into UTC timestamp, and store this timestamp only.
When a client retrieves these details, it receives the UTC timestamp only and converts it into local time in the same timezone as the client's current timezone. The client's current timezone is determined by the current system timezone setting, which I think is automatically adjusted based on the client's location (of course, assuming the client is connected to a mobile network).
My main motivations for this design are:
UTC is an absolute and universal time standard, and you can convert to/from it from/to any timezone.
Users only care about the local date and time in the timezone they are currently in.
Is this a feasible design? If not, what specific scenarios would break the application or severely affect user experience? Critiques welcome.
For a single event, knowing the UTC instant on which it occurs is usually enough, so long as you have the right UTC instant (see later).
For repeated events, you need to know the time zone in which it repeats... not just the UTC offset, but the actual time zone. For example, if I schedule a weekly meeting at 5pm in Europe/London with colleagues in America/Los_Angeles, then for most of the year it will occur at 9am for them... but for a couple of weeks in the year it will occur at 8am and for a couple of weeks in the year it will occur at 10am, due to differences in when DST is observed.
Even for a single event, you might want to consider what happens if time zone rules change. Suppose I schedule a meeting for 4pm on March 20th 2018, in the Europe/London time zone. Currently that will occur with a UTC offset of 0... but suppose between now and the meeting, the time zone rules change to bring British Summer Time in one hour earlier. If I've written it in my diary as 4pm, I probably don't want the software to think that it's actually at 5pm because that's the UTC instant we originally predicted.
We don't know your exact application requirements, but the above situations at least provide an argument for potentially storing the local time and time zone instead of the UTC instant... but you'll also need to work out what to do if the local time ends up being skipped or being ambiguous due to DST changes. (When the clocks fall back, some local times occur twice. When the clocks skip forward, some local times are skipped. A time that was unambiguous may become invalid or ambiguous if the rules change between the original planning time and the actual event. You should probably account for this in your design.)
To keep it simple, my answers are:
Timezone info is redundant if you want to define a single moment. A
UTC/Unix timestamp completely defines a moment.
Your design seems feasible but on point 2: i would convert to the UTC/Unix timestamp on the client-side and already give this timestamp
in its final form to the server. Reason: the client-side already has the info necessary to convert (see this time-keeping
client-server-db
architecture
example - it works based exactly on the principles you describe).
One possible problem (as described by Jon Skeet in his answer) are recurring events, but this should be reflected in the way you model
time. The difference between recurring events and fixed events is
that the latter completely define a moment (like a UTC/Unix
timestamp) while the first are only a 'function' which can be applied
to the current time to get the next trigger time of the recurring
event. But this might entirely be a different problem than what
you ask - in any case, somehow distinguishing between recurring
events (if you need them) and fixed events in your model is a good
idea.
One decision to make is: PULL or PUSH? Or both? Do you want the server to be able to send emails for example, when an event comes to
pass? Or do you want client-side alerts only when your client-side
app is running? The answers to these questions will help you come
towards a design suitable for you.
I have web application which controls the stores locate din different time zones.
In this web application user will set rules that, any particular product is in discount for any given period of time i.e. 1-Aug 2014 to 5-Aug-2014. so how can this rule be executed in web application. this info can be inserted from anytime zone. but store in Europe and Store in US should have to make this product available from exact 1-Aug-2014, Europe will be early compare to US.
SO how we can handle this kind of scenarios.
In general:
Store the time zone for each store, such as America/Los_Angeles or Europe/London.
When checking for discounts, get the current UTC time and use the store's time zone to determine the appropriate local time.
Compare that local time against the expiration date for the discount.
This assumes that the business rule is to rely upon the store location's time zone. This might not necessarily be the case - as many online stores serve customers worldwide without regard to where the physical store or product is located. In that case, you need to determine who's time zone is applicable. Is it a single fixed time zone for the whole company? Or perhaps it's aligned the end-user's time zone, such that those in different time zones would have the offer expire at different times. You'll need to decide what is appropriate for your particular business.
Sorry I can't be more specific, but you didn't provide many details to go on. If you need further assistance, please consider editing your question to include details such as what language and platform you're using, what code you have tried, and what the specific business rules are.
We have a website that has a large number of events that have dates and times created by admins. Admins choose a time zone for each date time entered, and they are stored in UTC time. We are trying to support a global audience, and be completely localized in terms of dates.
We have a search page, that allows dates to be entered as search criteria.
So users could say, show me all events between "12:01 AM July-1-2011" and "11:59 PM July 10-2011".
I'm trying to figure out what the best approach is to determining what time zone to consider the date filter criteria in.
Force end users to select a time zone when creating a date filters. This is cumbersome, and our designers our pushing back. It is what I would prefer.
Assume the the entered dates are in the users "preferred" time zone, which is set upon logging in.
Store times in Local time, without converting to UTC. This way the end users are searching in the admin created date. I hate this idea, i need help explaining why this is bad.
Please help!
Second option is possible solution to your problem. And it is probably the best.
Possibly you could get current time zone offset from web browser (with JavaScript) but the problem is, there are certain time zones that currently have the same offset but Daylight Saving Time switches on different dates, therefore search result would be inaccurate. By having User to choose his/her prefer time zone and storing that information in the profile, you could always present correct dates and times, as well as use this information for searching. However, I would add an information near search box, so that end User would know what time zone this refers to (with JavaScript that would be obvious: the current one, with profile User might forgot).
BTW. Time zone information is best to show as "UTC+02:00 (Warsaw, Zagreb, Skopje)" instead "Central European Time"...
As for other options:
1. Too much clicking. As well as "don't make me think, I want to have it in my local time zone, isn't that obvious?".
3. Local times will not be comparable against each other. You will soon end up with two different dates referring to the same point in time (at least in terms of the numbers). Really bad idea.
I would like to be able to display time based on the user's current time zone. I will be storing times in UTC format in my database, but wish to normalize these to the client's time zone. So far the option that seems most viable is to capture the clients time and then deteremine the difference between that and current UTC and use that delta to normalize times when rendering. I would like to know if there are any more straight forward options available to detect and normalize a UTC time to that of the requesting client's machine.
I would use the javascript dateObject.getTimezoneOffset(). Even if their time isn't set accurately, hopefully they've set their timezone:
http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp
You can use this value to calculate an offset between the server's time and the client's time. (as Jason helpfully pointed out in a comment below)
In addition to, or instead of using getTimezoneOffset, you should consider permitting the user to specify preferred timezone in their profile. For instance, a user may be visiting in one timezone, yet may prefer to see time displayed in his home timezone.
Also, if this were as simple as calling a JavaScript function, then sites would never have to ask for your timezone.
A much better approach is to store per-user the exact time zone the user is in (and optionally) allow them to select if they observe daylight savings time (if it's applicable to their time zone.) You can of course, automatically fill in the DST information (based on the time zone) if you wanted.
You'd have to make this part of the sign-up or possibly in their "options".
I want to implement timezone in my web application. I researched and saw most web app use a GMT dropdown, here is the link to that dropdown http://www.attackwork.com/BlogEntry/6/Time-Zone-Dropdown-Select-List/Default.aspx
Then I saw this article suggesting UTC is the way to go when it comes to implement timezone. https://web.archive.org/web/20210513223048/http://aspnet.4guysfromrolla.com/articles/081507-1.aspx Basically it's saying don't use DateTime.Now instead use DateTime.UtcNow
My questions are,
Is there a dropdown of the timezones in UTC, like the first link I showed there is one on GMT?
Should I really use UTC or GMT?
.NET 3.5 provides the TimeZoneInfo class which should make it relatively simple for you to populate a dropdown with time zones. GMT came before UTC and UTC was officially instituted on January 1, 1972. See this link for more information. For today's purposes, the two are pretty much synonymous, though they have different historical origins. Use whichever looks and functions better for your purposes.
I'm not sure if this is what you intended to ask, but in your database you should always store timestamps in UTC/GMT (as noted by others they mean essentially the same thing). For each user of your web app, store the time zone preference.
Then whenever you display the timestamp for something to a user, convert the UTC time in the database to the user's timezone.
GMT (Greenwich Mean Time) is the same as UTC (Universal Coordinated Time). This isn't an either/or choice - use it :)
Use Localization settings, functions and features anywhere possible.
If you aren't running against SQL Server 2008 or don't want to abstract timezone management to the database, you should store all times as UTC/GMT and apply the timezone difference based off the user's profile setting, so that users from all around the world can see timestamps on events in their local time.
The distinction between UTC and GMT is probably too fine to bother with in your code. However, it's probably a good idea to always save and process times internally with zero timezone offset, and deal with it as a presentation concern.
It's also possible to use JavaScript to determine the user's probable timezone: examine the timezone offsets for some pair of Date objects reasonably close to the solstices (even January 1 and July 1 makes a suitable approximation) to obtain a coarse timezone identification. Feel free to use this information to determine a default timezone, but do allow it to be changed by the user: JavaScript doesn't provide sufficient detail to select the exact timezone with national and regional historical shifts, and it may not be enabled by the user anyway.