We have an app hosted on a server in the UK that is accessed by customers all over the world. Our customers open an order for their company which is added to over time. One of the things they need to do whilst setting up their order is to select an order closing date at which point the order is closed automatically and submitted.
We want to close any order at midnight (local time based on timezone) on the date that is selected by the customer but this poses a problem when we take different timezones into consideration as our server is in the UK. Our server needs to know at which UK time to close the order so that the customer sees their order close at midnight their time.
We are asking customers to enter their timezone as part of the setup of their account so we are storing that in the database as a .net timezoneinfo id. We will also store the targetCloseDate which is say 30 Sep 2012 (in order to display the to user). However we need to convert the target date to a UK time that our server uses as the order close date.
How do we do this conversion?
Cheers
Wing
Have answered this myself after looking more into the timezoneinfo class. You can use:
TimeZoneInfo.ConvertTimeBySystemTimeZoneId(orderCloseDate, customerTimeZone, TimeZoneInfo.Local.Id)
This converts a datetime value - orderCloseDate using a source timezone and a destination timezone... perfect!!!
Wing
Related
I'm working in a scheduler web application and my client (Angular) and server (Asp.net core) timezones are different.
The client is in any timezone. Let´s use (GMT-3).
The server is UTC.
Let´s suppose this case:
One user schedule an event to it´s local time at 08:00AM.
When send this information to serve, it will save 11:00AM in database.
So, when user retrieve this information, client will convert back to 08:00AM due to -3 hours timezone.
But, if this schedule was made to a date in future, when client's country will be in daylight saving, it will convert back to -2 hours. So it will converted to 09:00AM to the client, and that is wrong.
How to deal with daylight saving time when I get dates from server?
Simply, date and times should be stored in UTC. You can always get from UTC back to the user's time. The problem with storing a datetime with an offset is that the offset is not contextual. For example, let's assume that the user is in DST with a timezone that is normally -3 offset from UTC. As such, their current offset is -2. You store the -2 offset, and now what? Is it -2 because they're in a zone that's -2 or is it -2 because it's a -3 zone in DST. There's no way to know. In effect, you've failed to capture critical information.
You don't have this issue with datetimes stored in UTC. You can simply get the user's current time, including their current offset (DST or not) and compare that with the times in your data store. You may need to convert the user time to UTC first, but in many case you do not. For example, the DateTimeOffset type is smart enough to be able to compare taking offset into account. Many databases support this as well for offset-capable column types.
If I understand the issue correctly, you want to keep the server using UTC stored date/times and have the client display local time while handling the DST. I recommend using the angular2-moment, Moment & Momemt-Timezone npm packages. This package will be able to automatically handle the DST when you provide the iana_timezone like America\Chicago.
moment.tz(<utc-date-time>, <iana-timezone>).format()
This will handle all the necessary conversions you need in the client.
See Stackblitz example
Also checkout the Moment Timezone Docs
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.
If server is located in US and website user is from Asia, when user add a new comment, he sees that the comment is added 10 hours ago because there is 10 hours timing difference in Asia and US.
What I want to do is when displaying comment, automatically convert date time to the time of target country or region where user come from.
Track user region/country
DateTime in any webpage should be converted to that country time
So that I can display user that he posted comment a few second ago...
Handle all dates internally as UTC,
meaning 0 hour offset
Use the language/country part of the user-agent string or the ip address to detect where the user is from, and look up the timezone.
Use TimeZoneInfo.ConvertTime(..) to convert the UAC time to the users local time
Point 2 will be the most work unless you find some lookup table or existing code to do this.
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.