Is something wrong with code.
var mom = moment("23-11-2016 00:00", "DD-MM-YYYY HH:mm");
alert(mom.toISOString());
//result 2016-11-22T17:00:00.000Z
Why the result is not 2016-11-23T00:00:00.000Z? How I can get 2016-11-23T00:00:00.000Z result?
As the doc says:
By default, moment parses and displays in local time.
while .toISOString() always returns a timestamp in UTC:
Note that .toISOString() always returns a timestamp in UTC, even if the moment in question is in local mode. This is done to provide consistency with the specification for native JavaScript Date .toISOString(), as outlined in the ES2015 specification.
You probably have -7 hours offset from UTC.
Use format() if you want to display date in local time.
If your input string represents a UTC time, then use moment.utc(String, String);
Related
I have a simple class that contains a DateTime property. When I set the value of this property using DateTime.Now() the value is correct. However, when I pass this class object as a parameter via SignalR, on the receiving end SignalR has changed the DateTime so that it no longer matches the original DateTime. How can I get SignalR to stop manipulating my DateTime values? This issue seems to have started with a recent update to the latest SignalR nuget packages.
This seems to be a problem when the hub and the client are in two different time zones. It seems Microsoft is trying to help, by adjusting the date/time to the local time zone, but I want the original value, not the value Microsoft "thinks" I want.
When you want two systems to communicate with each other I would recommend using always the DateTime in UTC for various reasons. In your case you have two options here:
1 - Send the date as string string date = DateTime.Now.ToString(CultureInfo.InvariantCulture); so on the client side you just need to parse the datetime like DateTime.Parse(date, CultureInfo.InvariantCulture);.
2 - Send the date in UTC like DateTime.UtcNow; so event if the SignalR tries to change the date, it will have the DateTime.Kind as UTC. In this case or you will get the current date correctly, or you just adjust on the client side to the local time like receivedDate.ToLocalTime();
This one was a real head scratcher as I had the exact same issue. The client was storing the correct time but by the time it hit the Hub... it had changed. I'm really glad you posted this as I wouldn't have imagined this issue being possible. #Kiril1512 posted the correct resolution. In my case I used his second option as I didn't want to change my model... although simply converting to a string would have been simpler. While I did follow his suggestion and convert everything to DateTime.UtcNow()... I am thinking this was unnecessary as I noticed even previously stored dates converted correctly. This makes me think that either this isn't necessary to do, or dates are converted to Utc when they hit the Hub automatically which may be what the issue was to begin with?
Either way I posted this as I discovered that converting this date back to Local time was a little more involved. Here is how I ended up doing the conversion which resolved this issue for me that I gathered from this resource:
DateTime convertedDate = DateTime.SpecifyKind(
DateTime.Parse(msg.CreatedOn.ToString()),
DateTimeKind.Utc);
var kind = convertedDate.Kind;
DateTime dt = convertedDate.ToLocalTime();
I am using moment timezone to set default time
$moment.tz.setDefault('Europe/London');
$moment().toString();
is providing me the time in the defined timezone. but I need the timestamp. so I am using
$moment().now();
but it's returning the timestamp in local timezone. how can I get the timestamp of the default timezone(Europe/London)?
Moment.now is not really a public api. It is intended to be used for testing purposes only. All that you want to do is format a moment, so your code would be as follows:
moment.tz.setDefault('Europe/London');
moment().format(); //"2016-10-18T21:57:39+01:00"
I am trying to use the plugin js calendarfull initialized and I would like the calendar.
and then stored in the db.
as I receive a date in FR, at first I call into IN with momentjs like this:
moment(new Date("01/05/2015")).format("YYYY-DD-MM")
it returns me well : 2015-01-05
Now if I try to change this date : 30/05/2015
to put it in EN told me the date is invalid
by cons if I use : 11/05/2015
he converted me well the date in EN
I feel that we are limited in the conversion of the dates from the time lag of the current date, since it is impossible to convert the date Date 2015-01-06ditla me it is invalid .
there would have a way to automatically convert the date momentsjs even a date more than 3 months?
Thank you in advance.
Don't create the moment instance from a string without specifying the format. It will behave differently on each browser. Instead, use the String + Format constructor:
moment("01/05/2015", "DD/MM/YYYY").format("YYYY-DD-MM");
// => '2015-01-05'
moment("30/05/2015", "DD/MM/YYYY").format("YYYY-DD-MM");
// => '2015-30-05'
From moment.js docs:
Warning: Browser support for parsing strings is inconsistent. Because
there is no specification on which formats should be supported, what
works in some browsers will not work in other browsers.
For consistent results parsing anything other than ISO 8601 strings,
you should use String + Format.
I've been using toISOString to serialize momentJS date before sending to the server via jQuery. It works fine for me except it converts date to UTC but I need to keep the local timezone. Does momentJS have a method for this?
You can either call .format() without any parameters, or you can call .toISOString(true). Both are in ISO 8601 extended format, the difference is only in whether milliseconds are included or not.
// get the current moment, in local mode
const m = moment();
// format without parameters will give the ISO string including offset
console.log(`moment().format() === "${ m.format() }"`);
// if you want to include milliseconds, you can use toISOString(true) instead
console.log(`moment().toISOString(true) === "${ m.toISOString(true) }"`);
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.29.4/moment.min.js"></script>
Added in 2.20.0:
moment().toISOString(true)
Output:
"2018-05-13T16:16:13.507+03:00"
Found answer here.
Documentation.
Documentum (DQL via DFC) always returns Date result columns as a string formatted like this:
Wed Oct 19 16:01:59 PDT 2011
...and the .NET DateTime.Parse function chokes on this — especially the PDT time zone (TZ henceforth) part of the strings — as far as I can tell, there is no concept of these TZ abbreviations in the DateTime parsing. Sure, it'll understand +8:00 but not PDT.
The TZ is based on the TZ of the content server, which may not always be the same TZ as the consumer of the web service (we're feeding out the DQL results via web service).
SO... if I can get Documentum to ALWAYS give me the UTC time in those strings, I can do the conversion quite easily on the client and always have their correct time zone.
Can this be done? Is there a Documentum setting for the content server to always return GMT times?
Alternative solutions?
For date format see dfc.date_format = setting which you can define in your dfc.properties file.
An excerpt from dfcfull.properties for details:
date format can be specied using the syntax of the Java SimpleDateFormat class
What version of Content Server do you have? In D6.x dates are stored in UTC and transformed to local TZ of client by Documentum client apps. For more details see:
https://community.emc.com/message/545879#545879
For DQL there is a datetostring function and it is possible to use it like this
select datetostring(r_creation_date, 'dd/mm/yyyy') from dm_document
it will return 28/12/2014
or with time like this
select datetostring(r_creation_date, 'dd/mm/yyyy hh:mi:ss') from dm_document
it will return 28/10/2014 23:58:35
for DFC it is not recommended to use getString for dates. It is recommended to use getTime method. It will return IDfTime object that can be converted to standard Date object.