I have many users in different locales so they have different time zones. I have a field in one of my work items that contain a date. Whenever it is set, it is supposed to default to 12:00:00 PM in the anytime zone, but instead, it gets set to the user's locale and gets translated to the work item viewer's locale.
E.G. :
User 1 from (UTC-05:00) Eastern Time (US & Canada) creates a work item
with a date field 8/30/2022 12:00 AM
User 2 from (UTC-08:00) Pacific Time (US & Canada) views the same work
item, but the date field is now 8/29/2022 9:00 PM
This discrepancy has caused confusion. I want it so when displayed to the viewer, the field is 12:00 AM as opposed to a translated value from the server's time zone.
Right now the workaround is to ask all users to set everyone's locale to the same. As a Team Foundation Server administrator, is there a settings option to set all users' locale to the same? I've searched for answers online, but they all point to Azure DevOps Server fixes.
A secondary workaround I am considering is if there is a way to modify the work item type and force the field to be a certain timezone.
Related
I send a local date to my iCloud container, but when I query it, it returns a UTC date, does anyone know how to change this?
The date also seems to be inconsistent on the dashboard. As you can see, in the data list, the time is local. When I click on it and scroll to the time property, it's UTC.
From Date documentation:
A specific point in time, independent of any calendar or time zone.
So when you are querying the Date from iCloud I am pretty sure you are getting a correct one since it is free of any time zone, so it's dependant on the formatter's locale/time zone when it comes to displaying it.
The date you seen on the record list is date formatter for the locale and timezone of your system. The date you see when you open record details is the same point in time but displayed as UTC date.
e.g. I live in Poland and my timezone is UTC+2 so for me the same Date (point in time) is displayed in the dashboard like this:
We have a solution hosted on a server which uses Dialog Flow to convert our utterances to intent.
Example utterances: What are the activities for today, What are the activities for tomorrow, What is for lunch today. What is for lunch tomorrow.
We use entity: #sys.date-time for today/tomorrow. In response to these Dialog Flow sends us a date and time in this format (date, noon and time zone): "2021-05-18T12:00:00+06:00" (+6 seems to be India IST TZ).
A person can request these queries from anywhere in the world, hence today and tomorrow is relative to where the person is residing. We do know the TZ of the person requesting the service.
We use the Dialog flow's date, time and TZ and the TZ of the user and calculate the users date. The date comes our incorrect. Reason being that Dialog is always returning Time T12:00:00. If DF gave current time + TZ, our calculations would be correct.
How do we have Dialog Flow return actual time and not noon for Today/Tomorrow, so we can calculate the correct date for the user (using user's TZ - Time Zone).
You can pass an IANA time zone identifier such as America/New_York or Asia/Kolkata in the timeZone value in the query parameter, or set a default in the agent settings.
From the DialogFlow ES documentation:
timeZone string
The time zone of this conversational query from the time zone database, e.g., America/New_York, Europe/Paris. If not provided, the time zone specified in agent settings is used.
Also, India's time zone uses a +05:30 offset. If you're seeing +06:00, that could be any of 10 different time zones, but it's not India.
I'm having a trouble when develop multiple timezones website.
Currently I'm storing time in UTC after some researches and it is working fine in most cases.
But there is one case that I couldn't find solution for it:
There are two kinds of user in two countries which are United States
and Thailand.
User in Thailand is worker (A).
User in US is manager (B).
When A starts working, their activities logged into our system and B
can watch those via a monitoring screen on web app and they can choose
the date on that.
Example user A starts working at 8 AM on 23 June with mobile
app, when B chooses 23 June date on the monitoring screen, they
can see the activities of user on Thailand on 23 June (because the results is queried by UTC time), but the
problem is he should see the activities on 22 June instead of 23
June because the time in Thailand is faster than United States 12
hours.
How can I show to user B activities of user A when he chooses the date 22 June?
You've not asked about any particular technology stack or implementation, so I can only answer from a general perspective.
Concepts worth understanding:
Thailand has a single time zone, which has an offset of UTC+7 all year.
The US has multiple time zones, whose offsets range from UTC-10 to UTC-4, depending on what part of the country you are referring to, whether or not daylight saving time is in effect, and whether or not a particular location observes daylight saving time. (Most of the country does, but all of Hawaii and much of Arizona does not.)
A "date" is just a year, month, and day on a calendar, but the time that which a date is observed is different depending on the time zone of the observer. There is a good visualization of this at everytimezone.com.
In your situation, you will have to decide the behavior you want depending on the specific needs of your application:
Do you want the period shown to represent all activities on the date as observed by the person choosing the date? If so, then determine the start of the current date and the start of the next date in the local time zone of the person selecting the date. Convert those to UTC, and query for all events in that UTC time range.
Example:
Example Activity Time: 2018-06-23T18:00:00+07:00 (Asia/Bangkok)
Stored as UTC: 2018-06-23T11:00:00Z
Date Selected: 2018-06-23 (America/New_York)
Local Range: [2018-06-23T00:00:00-04:00 , 2018-06-24T00:00:00-04:00 )
UTC Range: [2018-06-23T04:00:00Z , 2018-06-24T04:00:00Z )
Query: ... where ActivityUTC >= '2018-06-23 04:00:00' and ActivityUTC < '2018-06-24 04:00:00'
Or, do you want the date selected to always represent the date of the activity in the time zone of the person who recorded that activity, regardless of the time zone of the viewer? If so, then store that local date in a separate date-only column and just query on it without regard to time zone.
Example:
Example Activity Time: 2018-06-23T18:00:00+07:00 (Asia/Bangkok)
Local Date Stored: 2018-06-23
Date Selected: 2018-06-23
Query: ... where ActivityLocalDate = '2018-06-23'
Note, you might still store the UTC date and time in some other field, but it isn't relevant for this particular query.
From prior experience in the time and attendance industry, I can say that if it were me I would want the second option - as workers are typically paid based on their own time zones, not on those of their manager. However their are indeed edge cases and you'll have to decide for yourself which approach best matches your business requirements.
This Answer is specific to MySQL.
If you want B to see what A's clock says, use DATETIME; it will say 8AM.
If you want B to see A logging in in the middle of the night, use TIMESTAMP.
(This extends to A vs B, and to date as well as clock.)
Twice a year, DATETIME has a hiccup between 2AM and 3AM if there is a switch between standard and daylight-savings time.
I'm keeping the current date in a model using a datetime field in which I am indicating default to take the current date as a value.
_defaults = {
'f_inicio' : lambda *a: datetime.now().strftime('%Y-%m-%d %H:%M:%S'),
}
Assuming that the current date is '07/10/2013 17:24:05 ', in the view is the date '07/10/2013 12:24:05' and rectified in the database and the date is '07/10/2013 17:24:05'; gather that this subtracting five hours. The user can set the time zone 'America/Bogota', Colombia is in the region (GTM - 5:00). But do not understand how to properly show when the user since I get a totally different value that should show. Apparently this taking as 'GTM 0' the GTM Colombia. Taking the approximate date create_date field that should have given me as default is '2013-10-07 22:24:05.384'.
Anyone have any idea what may be happening, really appreciate any help on this issue that is driving me crazy.
This drived me too crazy in the past. This is a real simple issue.
The date stored in the database is UTC (GMT-0) timezone. Assume that the person is set with timezone GMT - 5:00, then while storing the value to the database, the date will be added with 5 hrs (exactly 5, not little more or little less) and thus we get the UTC time to store into the database. Now when displaying the same it will check for the users timezone and it finds that its GMT - 5:00 so the database time will be subtracted with 5 (again exactly 5, not little more or little less) and displayed the user.
This will be great for system which is used in different timezones. So the understanding is the input is taken in the user's timezone stored in UTC(GMT-0) and displayed to user's timezone (even if the user viewing is in the different timezone the time will be accurate to their timezone)
Note: if the user is not set with the timezone the browsers timezone is considered and will be used with the warning icon on the top corner
That's it. Hope this gives u better clarity!!
Right, this is a bit confusing for me, so I'm going to try and explain from the top!
I have a rails web app. It's an internal company app and will only be used in the UK.
One of the things the app does is manage meetings.
Meetings have a date & time when they start. There's a date/time picker on the form which allows the user to pick the date & time the meeting is for. I save this date AS IS into the database. All meetings last 2 hours, so the end time is simply start + 2 hours.
Example:
2013-06-23 6:45PM in the form is stored in the db as 2013-06-23 18:45:00
2013-12-23 6.45pm in the form is stored in the db as 2013-12-23 18:45:00
Note that the first date is during Daylight Savings (BST) and the second is during GMT. I don't actually care whether it is GMT or BST: the meeting happens at that time, absolutely.
Inside the rails webapp, I simply print out the exact date & time from the DB - formatted nicely, of course!
Now, at some point I send an email to the organiser of the meeting, and the person they're meeting with. This email tells them the the date & time of the meeting etc, and also includes an iCal (.ics) file for them to put into their (Outlook usually, but also Apple or gmail) calendar.
The issue I am having is that (using the above examples) Outlook shows the meetings like this:
Meeting #1: Start: 23/06/2013 7:45pm, End: 23/06/2013 9:45pm
Meeting #2: Start: 23/12/2013 6:45pm, End: 23/12/2013 8:45pm
Note that it has adjusted the first one because of the BST/GMT thing.
The text of the .ics file contains this code:
Meeting #1:
BEGIN:VCALENDAR
...
DTEND:20130623T204500Z
DTSTART:20130623T184500Z
...
END:VCALENDAR
Meeting #2:
BEGIN:VCALENDAR
...
DTEND:20131223T204500Z
DTSTART:20131223T184500Z
...
END:VCALENDAR
So I am encoding the dates/times using the Z timezone (UTC). I understand this is why Outlook mis converting the UTC time into the BST time for #1 and leaving #2 alone (because GMT == UTC)
My question is: how do I stop this happening? I want the time the meeting is scheduled for to be the absolute, actual time, regardless of GMT/BST: 6:45pm
Should I be storing the date-times as UTC in the DB? How would this be done (I assume it would apply to all dates, not just meeting start dates). And how to re-convert them back into the actual datetime when I display them in the webapp?
Extra:
I have an entry in my initializers/time_formats.rb like this:
:ical => "%Y%m%dT%H%M00Z"
So dates come out like "20130623T184500Z". I use this when building the ics. And this I think is the issue - if the date/time is during BST I don't want to be using Z, but something else?
Your problem is your date/time format. You have:
DTSTART:20130623T184500Z
in your .ics file and this corresponds to 19:45 BST (as British summer time is UTC+1).
There are a few things you should do. First, you can simply remove the 'Z' from the end of your dates. This means that the times inherit the timezone of the calendar, or the underlying application.
This will work assuming that the machines which are running Outlook are all in the Europe/London timezone. If not, or if you want to be a bit safer, you should also specify the following after your BEGIN: VCALENDAR line:
X-WR-TIMEZONE:Europe/London
This specifies the default timezone for all dates which are not specified explicitly.
Finally, if this does not work for any reason then you need to define your datetimes explicitly. First you need to add a timezone definition for Europe/London to the calendar. The info you need is available at http://www.tzurl.org/zoneinfo-outlook/Europe/London.ics. Then you need to ensure that all datetimes are of the format:
DTSTART;TZID=Europe/London:20130623T184500
This last approach is the best, as it means that if your requirements expand to other timezones you will be able to handle them relatively easily.
Sorry to answer this myself, but in case anyone else runs into this here's what I found was the cause of my particular issue. Note that the answer above re timezones also makes sense!
My rails app is storing UTC datetimes in the DB (as is default)
But, it also thought it's own timezone was UTC, which also seems to be the default.
The upshot of that is essentially it was storing local dates, local to UTC anyway. Changing the app to know it was sitting in Europe/London made it so the dates in the DB are all now accurately UTC (meaning, they're an hour off if I'm currently in BST)
I can now use the Z datetime format in iCals, and outlook and the rails app both convert the UTC date back into the actual datetime for the viewing-user's locale (Europe/London for everyone at the moment). This is what I wanted.