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.
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've created an email form using Infopath. (2007) It contains, first name, last name, date, time from and a time to field. I have supervisors enter the information on the form and submit it to our resource management department. The supervisors are in Central time, and the resource management department is in Eastern time. If the supervisor enters 9:00 AM, when the resource department opens the form it says 10:00 AM. Do you know of any way I can correct this? I've played with the time formats to use the ones without the * that says they are tied to the systems time clock but it doesnt seem to help. Thank you for any input you have! :)
http://community.office365.com/en-us/forums/153/p/63976/244291.aspx#244291
seems like a bug , sharepoint server changes the time zone
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
I have a question about dealing with date & time in my web application. The application will sell monthly subscriptions. It shows dates only when clients buy and cancel subscriptions. Clients can buy additional services in the middle of the month. Application calculates a pro-rata to charge the client until his anniversary date.
I will store dates/times in UTC. It is only for US clients.
I am considering the following options and I would love to get feedback from more experienced developers:
1 - always present dates in EST. I can include a small caption explaining that all subscriptions uses EST. This would be simple as I would not have to deal with clients' timezones. However I am not so sure if clients would be put off by this. Any thoughts?
2 - always present dates in EDT. This would probably not work very well as it would be harder to explain the reason for using it. However I believe it would be simpler to process than EST.
3 - ask for client's timezone information when he signs up for the service and use that information. I don't think this would add too much complication, however I would have to offer them an option to change timezones and I would have to decide what to do with existing subscriptions when there is a change in timezone. If I go with this option I would ask the client to pick the timezone from a drop-down list.
4 - ask for client's location (City and State) and calculate the timezone myself.
5 - try to guess client's timezone based on his IP or another method (ideas???).
Options 3, 4 and 5 would probably be the most user-friendly. Option 1 seems to be the most straightforward to implement.
Sorry for the long post. If you took the time to read it, would you mind taking a little more time and sharing your thoughts and experience?
Thank you.
UPDATE 1 - 9/3/2011 - 17:08 MST
Just found out that PayPal records transactions using PDT and shows them to the client using the client's local timezone they setup when they signed up with PayPal.
I am now inclined to:
1 - show current date using PDT (to align with PayPal) - I will probably change the code to show date & time PDT. Currently I am only showing the date. I believe it will be clearer to the client if I also show the time.
2 - I will not show the anniversary date. I will let PayPal handle that. I will simply state that it is a monthly billing.
3 - When clients add a new service I will calculate the pro-rata using PDT and I will give them a three day grace period to account for timezone differences (thanks to Robert Levy below for suggesting it) and PayPal processing (I don't want to charge them a pro-rata amount if they are only a couple of days from their regular monthly charges).
Any thoughts?
Update 2 - 9/3/2011 - 21:01 MST
Just a quick update. After further research I found out that PayPal does send me a transaction date back. I am not going to show any dates until the client pays at PayPal and I receive confirmation. I will show PayPal's transaction date in the client's receipt.
Sounds like a plan. What do you think?
Just add a grace period of 24 hours from UTC. Easy to code, no extra UI, and unlikely to upset any customers.
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.