I am having some troubles dealing with the SharePoint date system, and I was hoping to find some advice here. The problem I am facing is that every time I use JS to save a new item to my SharePoint list, the date that I pass (simply yyyy-mm-dd, no time included) is saved as a day earlier than I intended. I am almost certain I know why this is- the timezones are different. While I am at -4, the server is at +1. I am not familiar enough with how SharePoint receives and stores dates to know how I should proceed to get the dates to work properly. Any suggestions would be appreciated.
SharePoint datehandling 101 is that it always store the dates in UTC, that is +-0. When using the gui SharePoint automatically translates the time to your local time. Hence, the date and time you get is the UTC version and when saving datetimes through an API you must ensure if the API is localized or not, if it isn't then store the datetime as UTC.
Related
I've been reading a whole day today. I want to understand how to manage time in my webapp. So just a few bits of information to begin with: I have Laravel 9 backend and Vue3 frontend - a monolith app.
On the front end, users can create an entry in the database which contains the start and end date.
Now the problematic thing - so I want to make it so that when a user in one country creates the entry, that user will see their local time but if the user in another timezone sees that entry on the website they will see that shifted accordingly to their timezone.
Now if on the front end I am using new Date () in JS to obtain the date like this Tue Dec 27 2022 19:40:08 GMT+0000 (Greenwich Mean Time) and then send it over to laravel I get something like that in database 2022-12-27 19:40:08.
Here is what I know:
UTC is not a timezone but a time system
new Date() called in my JS app in the browser is giving me the local, time-zoned time
Laravel by default uses UTC
Both dates on the frontend and database in Laravel are the same. How that is if once of them is local time and the other one is UTC?
Can anyone explain exactly how does that work from database/js/laravel point of view? Or at least point me to some good resources?
The way I see that is I need to:
create UTC date in JS on the frontend
send it to the LAravel app which will save it in UTC in my db
display it for the user after formatting it on the frontend with Javascript to use local timezone.
It all seems very confusing to me and so far I just managed to get mostly mean comments for not understanding this.
I am mostly interested in understanding what is the correct flow here and how when I send a date from Javascript to the backend, Laravel knows how to deal with it.
Can anyone explain that?
I'm trying to build a dashboard indicating how much free time a set of employees has based on their calendar so we know who has time to work on different projects. I'm using the Google Calendar APIs and can't seem to get everything I need to build this information. I could really use a sanity check. I'm hoping that I'm missing something obvious.
What I'm specifically trying to do is to determine how much free time there is in a user's calendar between 8a and 5p in their local time zone. Even more specifically, only calendar events that they've accepted should be counted as "busy" since there are always a number of optional events on their calendar. I've tried accomplishing this in a couple of ways, but keep coming back to the same issue, timezone.
I can get the current timezone of the user's calendar by calling https://developers.google.com/calendar/api/v3/reference/calendars/get with the appropriate calendar ID. This returns a timezone in IANA format (America/Denver for example). However, all of the other Google APIs I would use to retrieve information (Freebusy, or events list) require you to provide a start time and end time in RFC3339 format with a mandatory offset (2022-10-28T08:00:00-06:00 for example). So even if I know that I want to retrieve information from October 28, 2022 from 8am to 5pm, I don't have an offset to work with.
At this point it seems like I need:
To be able to convert the IANA string into the current timezone offset (accounting for DST)
To be able to retrieve the current calendar's timezone offset, rather than an IANA string
To be able to call the Google Calendar APIs without a specific offset, but provide an IANA timezone
Someone to tell me I'm going about this all wrong.
Any and all suggestions are greatly appreciated!
I'm using FormatJS library along with Handlebars to display a list of events that occured in the past. I'm calling for an endpoint on my server's REST API which returns me the list of events in Json, with datetimes to display for each event. ATM I'm saving datetimes in the DB using GMT time zone.
So when I'm getting my Json, I'm handling datetimes like this :
{{formatRelative commentDate}}
My issue is, since the datetimes are stocked in GMT, they display also like that. For example, since I'm on a GMT+2 timezone, as soon as a new event is created and shows up on the list, I see it "happened 2 hours ago" while it should be "a few seconds ago".
So, is there a way I can handle this ? Am I making a mistake in saving datetimes in GMT in my DB, and if so, how would you handle datetimes coming from different timezones and displaying them to people in other timezones ?
Of course I could customize the formatRelative helper to play with getTimezoneOffset and get the wanted result, but I wanted to know if there is something better to do.
Thanks a lot ahead !
The key to understanding your question is what you wrote in the comments:
Getting the Json, containing datetimes in the format 2016-02-28 10:15:53 - that's UTC time
You should ensure the value in JSON is in full ISO8601 format, including the appropriate offset or Z character to indicate UTC: 2016-02-28T10:15:53Z
Without the offset, most implementations will consider the value to be represented in local time, which explains your results.
Thus, the problem is with your server-side code, not your JavaScript code. There may be a client-side workaround you could apply when the date string is parsed from JSON, but really the best solution would be to qualify it at the server.
I'm about to go insane dealing with datetime issues and the web.
I have a web server hosted in the Central Time Zone. When clients in the Eastern Time Zone try and schedule an item for a given day using my app, they pass in the value of (for example) 3/14/2015. When we pass the code back to our model, which is sent to the web api, we persist is using something like the code below.
moment.utc($("#mydatepicker").val).hour(0).minute(0).second(0)).toISOString();
This results in a string like the following:
2015-03-14T04:00:00.000Z
When the item is converted back on the server in web api, it converts to
3/13/2015 11:00:00 PM
Logic then strips off time and you can see what happens from here. Since I stripped off the time, it is now the day prior and that is the value persisted to the database.
I need to know some way to send a value from moment, into the web api preferrably as a ZonedDateTime in the client's time zone. I can then convert it to UTC for persistance in the DB.
I've seen things about using NodaTime.Serialization.JsonNet, but I am unclear on how to to use it with Moment and pass it back and forth across web api/ajax.
I need to know some way to send a value from moment, into the web api preferrably as a ZonedDateTime in the client's time zone. I can then convert it to UTC for persistance in the DB.
If that's what you want, then:
In your moment.js code, use .format() instead of .toISOString(), which will still give you an ISO8601 string, but will include the local offset instead of setting it to UTC.
In your ASP.Net code, define your values as a DateTimeOffset (or a noda OffsetDateTime) rather than a DateTime.
However, I don't think that's really what you want. When it comes to dates and times, context is super important. Here, you said you were picking a date from a date picker. When you do that - what time is being chosen by the user? In most cases, they aren't choosing a time - they're just picking a date. But since the JavaScript Date object is really a "date + time" object, it assigns midnight as a default time. Moment is no better in this regard.
Really, converting to UTC doesn't make logical sense when you are just talking about a calendar date. The string value you probably should be sending across the wire should just be a whole date, as in "2015-03-14". My guess is that is what you are starting with anyway. If not, then do moment.utc(yourvalue).format("YYYY-MM-DD") to get it. (Using UTC here is just a way to avoid local time zone issues, like midnight not existing in Brazil on the spring-forward day.)
This corresponds to the NodaTime LocalDate type in your .NET code. If you weren't using Noda Time, you would define the type as a DateTime and just ignore the time portion. In your database, if there's a date-only type available, then use it. For example, SQL Server has a date type.
I'd also encourage you to watch my Pluralsight course, Date and Time Fundamentals - which covers many of these issues.
Regarding using NodaTime.Serialization.JsonNet in WebAPI (so you can use LocalDate directly), in your WebApiConfig.cs file, wire it up like so:
config.Formatters.JsonFormatter.SerializerSettings
.ConfigureForNodaTime(DateTimeZoneProviders.Tzdb);
Then it should just work.
I would start by sending all dates and times to the server as UTC times. If you store UTC times only then you should be able to show the correct time that something is scheduled on the client side.
When you create your moment on the client side, do you run it out .toDate() first before sending it to the server side? What code are you running on the server side? Is it a .Net WebApi?
I want to run a scheduled job every 10 minutes which will do the following:
Check the table records and delete those who hasn't been updated for 10 minutes.
How is it possible to get the current server date in javascript in order to compare it?
Use the JavaScript Date object. Just creating a new Date object without parameters will give you the server date and time. It will of course be in GMT as all the servers in Azure run on GMT. However, be aware of clock drift. Each of the servers could be slightly off from one another time wise, so it may not be exact if comparing times across servers.
var cutOfDate = new Date();
You could also load up one of the JavaScript data libraries like Moment or something like that as well if you need to do a lot of date formatting or evaluations.
Another option is to simply have a stored procedure that is called to perform your clean up for you. The stored procedure could then use the SQL GETDATE() to determine the current date and do the deletes based on that.
I think what you want is this. Giving you an overview:
http://azure.microsoft.com/en-us/documentation/articles/mobile-services-how-to-use-server-scripts/#access-tables
For date and time
http://azureinmycloud.net/2011/10/26/working-with-datetime-now-in-windows-azure-apps/