Passing timezone to web api call from moment with nodatime
I'm going to go crazy with the problems of time and time.
I have a web server hosted in Central Time Zone. When clients in Eastern time zone try and schedule an item for a specific day using my app, they pass the value (for example) 3/14/2015. When we pass code back to our model, which is sent to the web api, we save something like the code below.
moment.utc($("#mydatepicker").val).hour(0).minute(0).second(0)).toISOString();
The result is a line similar to the following:
2015-03-14T04:00:00.000Z
When the element is converted back to the server in the web api it is converted to
3/13/2015 11:00:00 PM
Logic then cuts off time and you can see what happens from here. Since I turned off the time, now it is the day before, and this value is stored in the database.
I need to know a way to send the value from the moment in the web api is preferred like ZonedDateTime in the client timezone. Then I can convert it to UTC to save to DB.
I've seen things about using NodaTime.Serialization.JsonNet, but I don't understand how to use it with Moment and pass it back and forth via web api / ajax.
source to share
I need to know a way to send the value from the moment in the web api is preferred like ZonedDateTime in the client timezone. Then I can convert it to UTC to save to DB.
If you want, then:
-
In your time.js file use
.format()
instead.toISOString()
, which will still give you the ISO8601 string, but will include the local offset instead of setting it to UTC. -
In ASP.Net code, define your values as
DateTimeOffset
(or nodeOffsetDateTime
), notDateTime
.
However , I don't think this is really what you want. When it comes to dates and times, context is very important. Here you said you are picking a date from the pick date. When you do this - what time does the user choose? Most of the time, they don't pick the time - they just pick the date. But since the JavaScript Date
object is indeed a date + time object, it sets midnight as the default time. The moment is no better in this respect.
Indeed, the conversion to UTC doesn't make logical sense when you are just talking about a calendar date. The string value you probably should be sending over the wire should just be an integer date, as in "2015-03-14"
. I guess this is where you start. 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 zones, like midnight, which doesn't exist in Brazil on spring-forward day.)
This corresponds to the NodaTime type LocalDate
in your .NET code. If you haven't used Noda Time, you define the type as DateTime
and just ignore the time portion. In your database, if there is a date type available, use that. For example, SQL Server has a type Date
.
I also encourage you to watch my Pluralsight course, Basics of Date and Time - which covers many of these issues.
Regarding use NodaTime.Serialization.JsonNet
in WebAPI (so you can use directly LocalDate
), in your file, WebApiConfig.cs
include it like this:
config.Formatters.JsonFormatter.SerializerSettings
.ConfigureForNodaTime(DateTimeZoneProviders.Tzdb);
Then it should just work.
source to share
I would start by sending all dates and times to the server as UTC. If you only store UTC time then you should be able to show the correct time when something is scheduled on the client side.
When you create your moment on the client side, do you first run it .toDate () before you send it to the server? What code are you using on the server side? Is it .Net WebApi?
source to share