Suppose we have to save Norwegian time 9:00
If we are ignoring day light.In database in UTC we will save 8:00. In Display we will add +1 for Norway 9:00. In India we are adding +5:30 means 1:30 – it should be 12:30, 1 hour difference
If we consider day light then we should add user +2 for Norway Means in database we will save 7:00 And for Norway for +2 it will be 9:00 And for India it will be 12:30 – correct time. But in this case if we want to see old dates which we have added when day light was false with +1 But now if we show old dates by adding +2 hours. Then it will be 1 hour earlier.
MY Problem
What i am doing is getting local time entered by user.
and converting it to UTC by adding offset hour for user timezone.
And while getting i am passing offset hour for user timezone to SQL and in SQL i am converting UTC date to user local time.
and here the issue comes old dates which i have entered with +1 before 31 march.After 31 march as user offset will be +2 because of day light.So old dates shifted by one hour.
Please correct me where i am doing wrong in handling dates.
And how can i solve my problem
Related
We have the Datebirth field on Contact entity form. When a user picks the date 1 October 1983, the system automatically changes it to 30 September 1983.
However, this kind of magic doesn't happen with other dates.
The field behavior is User Local. Format is Date Only. Our timezone GTM +3. Crm converts it to GTM +0 on changing field value correctly. Also we cannot change the behavior.
What could be the mysticism of 10/1/1983?
We’ve been analyzing this problem for 2 days. Finally we found the core of the problem. The issue is that Sep 30 1983 and Sep 30 1982 are dates of daylight-saving time (DTS).
For example, when the date 1 Oct 1983 00:00 is picked and saved into database (MS SQL Server), it will be converted to the Greenwich Mean Time +0 (GMT +0). In our case (GMT +3) the time must be 09/30/1983 21:00:00.
But an extra hour is subtracted in function [DB_name]/Programmability/Scalar-valued functions/fn_UTCToTzSpecificLocalTime, because on switching to winter time the clock is put back an hour. As a result, the time 09/30/1983 20:00:00 is saved in DB, instead of 09/30/1983 21:00:00.
Therefore, when crm displays the time 09/30/1983 20:00:00 on a form, it converts it to local time (adds 3 hours). This is why we see 09/30/1983 23:00:00.
We added 1 hour in DB to solve this problem.
I have created a datetime column in sharepoint. There we have minute increment of 5 minutes only. So that I could not enter the time in format 3:22 pm only 3:25 pm or 3:20 pm can only be entered. Is there any way to do this.
#FRECEENA FRANCIS,
Even though the increment is 5 minutes, you can change the time to minute intervals by typing it in and saving. It will hold the time to whatever you type in.
I tested it on SPO/SP2013, i believe it works for other SP versions.
BR
The problem with changing the day of the week to reload heroic instances.
It's always Friday at 04:00.
I am trying to put in the config in the line:
Instance.ResetTimeRelativeTimestamp =
one of the other dates:
1552867201 = 18.03.2019 00:01 Monday
1552953600 = 19.03.2019 00:00 Tuesday
1553040001 = 20.03.2019 00:01 Wednesday
1552521601 = 14.03.2019 00:00 Thursday
1552608001 = 15.03.2019 00:01 Friday
1552694401 = 16.03.2019 00:01 Saturday
1552780801 = 17.03.2019 00:01 Sunday
Then I've cleared 3 tables in characters DB:
instance_reset
character_instance
instance
When I start the server - I see the same result - restart on Friday at 4:00.
Question: How to change the day of week? It must be Wednesday.
I actually just finished figuring this out myself. After much digging through the AzerothCore source, and it looks like the day of the week that instances are reset is chosen the very first time the server is started. As far as I can tell, ResetTimeRelativeTimestamp is not used to determine reset times. To be more specific:
The server starts up and starts to load instance reset times from the characters.instance_reset table
If an instance is missing an entry in the instance_reset table, an entry is added using the following formula:
Reset time = today(in UTC, rounded to nearest day) + RaidDuration(from mapdifficulty_dbc, named resetTime in code) + Instance.ResetTimeHour(from worldserver.conf)
Let's run through an example
You're in the US Central time zone, which is currently UTC-5. It's 2020_10_18 14:56:23, Convert that to UTC and you get: 2020_10_18 19:56:23. Round to the nearest day and you get UTC 2020_10_18 00:00:00
Let's say it's setting the reset time for ICC 10 man. If you look in mapdifficulty_dbc, RaidDuration is 604800 seconds, which is 7 days.
Let's say you have Instance.ResetTimeHour set to the default value, 4. This becomes 4 hours.
Plug this all in and you get resettime = 'UTC 2020_10_18 00:00:00' + 7 days + 4 hours = UTC 2020_10_25 04:00:00, a Sunday. Convert back to US Central time and you get: 2020_10_24 23:00:00 CST, a Saturday. Instances will reset on Saturday
The next time the instance is reset, its next reset time is reset using previous reset time + RaidDuration.
This means that if you want to choose the day of the week, you need to do one of the following:
Modify the instance reset times in the instance_reset table to be on the day of the week that you want. This approach is risky as it involves manipulating the reset timestamps in the DB directly
Empty the instance table, then start the server on the day you want instances to reset. Yes, this still involves DB manipulation, but at least the contents of the table are generated by Azeroth Core instead of yourself.
Here's what I did to solve the issue
The reason I've buried this so deeply in the answer is that you have to understand what you're doing before you start wiping out tables in your database. PROCEED WITH CAUTION.
Shut down the worldserver
Empty the characters.instance_reset table via SQL
Set your system time to some time before the current time that when converted to UTC falls on the day of the week you'd like instances to reset
Start the worldserver. Wait for it to load. Login and confirm that instance lockouts are expiring at the correct time.
Shut down the worldserver
Set your system time back to the correct time and start the server back up again
I have built a small calendar app. Events are stored in my database with Dates in UTC. My js code fetches these events and formats the UTC date to the local date of the user machine. Now I live in Sweden so if the UTC time is 10:00, the frontend should show 12:00. This works fine for me except when it comes to summer/winter time. In the frontend the user can set an event to repeat at specific dates. So for example I could set an event that starts at the 20 of every month to start at 12:00. However, lets say I add events from august to December. Events in August-October will show 12:00. Events from November to December will show 11:00. However, if I set a single event to start for example in December, it will show the correct date. What is the best way to deal with this?
This is how I format the utc date to my local date:
var d = moment.parseZone(startDate).local().format('L LT')
I am trying to create a daily event
Like from 14-sep-2013 to 18-sep-2013 between 10:00 UTC to 15:30 UTC. daily
I am using the following query
DTSTART;VALUE=DATE:20130914T100000Z\r\nRRULE:FREQ=DAILY;
UNTIL=20130918T153000Z\r\n;
It is creating a recursive event but for the whole day. I want event between the given time interval daily.
I am new to this. Please help.
Thanks
You're getting a full day event because your DTSTART has VALUE=DATE instead of DATETIME.
Also, the UNTIL specifies the last DTSTART, not the DTEND, so you'll probably need a DTEND:20130914T153000Z
Try
DTSTART:20130914T100000Z
DTEND:20130914T153000Z
RRULE:FREQ=DAILY;UNTIL=20130918T100000Z
To break it down:
The DTSTART says the first occurrence starts on 2013-09-14 # 10:00:00 UTC.
The DTEND says the first occurrence ends on 2013-09-14 # 15:30:00 UTC.
The RRULE says subsequent occurrences occur daily and the last one will occur on or before 2013-09-18 # 10:00:00 UTC.