I am using moment.js to parse birthdates:
moment(birthdate, 'DD.MM.YYYY')
If all date parts, i.e. day, month and year are available everything is fine. However there are people who dont have an exact birthdate. If only the year of birth is available the above parsing sets the day and month to default values that is the first January and this is wrong.
Can I create a moment object with unknown (nullable) values for the day and month?
No. The data stored by a moment object is a JavaScript Date object, which typically stores a Unix timestamp internally (exact number of seconds since 1970-01-01 00:00:00 UTC). This single value cannot represent anything other than an exact moment in time.
You will need to use a different structure to represent this "partial date" concept.
Related
A web request gives me '2022-03-01'.
I know that is and always will mean UTC 2022-03-01 at midnight exactly.
I need to copy that value onto another CRM date field on the Form
I tried:
var passDateToLib = Date('2022-03-01')
formContext.getAttribute("new_otherdatefield").setValue(passDateToLib)
That new_otherdatefield field is also configured to be a UTC Date only field.
But what ends up shown in the field, is 1 date BEFORE '2022-03-01'. So I suspect it's ignoring the timezone aspect of the Date...
toISOString() gives the time in ISO format. To get the date only as you mentioned we can use substring method to remove the time. This will basically give the date based on GMT and not for your Local TimeZone.
new Date().toISOString().substring(0,10);
I have the following data structure. The first column is intervals. The first row of the interval datum is a unix time and the subsequent data are intervals (i.e. 300*1, 300*2, ect). The other column is the data values. Here is the head of the data:
a1521207300,555.45
1,554.53
2,554.07
3,553.9
4,552.67
And here I went about converting the unix time to a Date object. The a here is ornamental, so I slice() at 1 like so:
var rawTime = data[0].interval;
var timeValue = Math.round(rawTime.slice(1));
console.log(timeValue)
console.log(new Date(timeValue))
I also tried using parseInt() instead of round(). The console shows that this unix time is equivalent to: Jan 18 1970 which I had quite the guffaw at. Then I got to thinking, maybe I did something wrong. It's supposed to be a very recent date -- March 16th 2018. This is strange because my understanding is that javascript can be passed a unix date directly as per this answer.
I also checked the unix time at a conversion site: www.onlineconversion.com/unix_time.htm
Which confirmed that it's indeed a March 16th 2018 timestamp.
Question: Why is this unix date for my March 2018 data being treated like a 1970's date? Maybe the a is actually doing something after all... Anyway, what is the correct way to handle this time stamp? It's only 10 numerical digits, it does not seem to be a precision problem. Date can handle unix times up to 13 digits I believe.
As per the documentation, when you invoke new Date(value) with an integer value, it is used as the number of milliseconds since January 1, 1970. To get the date you want, the value 1521207300 appears to be number of seconds instead of milliseconds. That is, you missed a factor of 1000. new Date(1521207300000) gives Fri Mar 16 2018.
When I take away new from new Date it seems to be ok. Not sure why though.
The documentation mentions the different behavior:
Note: JavaScript Date objects can only be instantiated by calling JavaScript Date as a constructor: calling it as a regular function (i.e. without the new operator) will return a string rather than a Date object; unlike other JavaScript object types, JavaScript Date objects have no literal syntax.
It seems when called as a function Date(value), it treats the value as the number of seconds, instead of milliseconds. I didn't dig deep enough to confirm this, because it doesn't matter: the documentation says to not use it this way (and since it gives a string instead of a date object, it's not very useful anyway).
I'm trying to compare two dates in javascript which are formatted differently. Namely:
2015-09-30T00:00:00 and 9/30/2015 12:00:00 AM
The former is UTC and the latter is not in UTC format. Logically, I am referring to the same date/time here but I can't come up with a way to compare them that will return true. Creating a new Date object with each ends up with different results (due to UTC offset with my local time zone).
What am I missing?
Ended up concluding that tagging on a "UTC" to the second date format before creating the Date object leads to an output consistent with the UTC formatted date.
I have a form where a user can enter a date, i.e. <input type="date"> the value is submitted in yyyy-MM-dd format. When I create a Date object with the string it assumes the time zone is the one the user's browser is set to – this is the behavior I want.
I'm then using the date value to make queries against a REST API that expects ISO date/time strings. That's no problem as the toISOString function on the Date object handles everything correctly.
However, when I'm unit testing this code – setting my input to a yyyy-MM-dd string then asserting that the output is an expected ISO timestamp string the tests can only work in a particular time zone. Is there a way I can force the time zone in the test?
I've tried using Jasmine spies to do something like:
var fixedTime = moment().zone(60).toDate()
spyOn(window, 'Date').andCallFake(function() {
return fixedTime;
});
But given there are so many variants of the constructor and so many ways it gets called by moment.js this is pretty impractical and is getting me into infinite loops.
A JavaScript Date cannot be set to a particular time zone. It only knows about UTC and the computer's local time from the environment it is running on.
There are time zone libraries for javascript, but I don't think that will help you here.
First, understand that "ISO" refers to ISO8601, which is a specification that defines a collection of related formats, such as YYYY-MM-DDTHH:MM:SS.
It is a separate concept from UTC, which refers to Universal Coordinated Time. UTC is the timekeeping system that we all synchronize our clocks to, which uses GMT as its basis - that is, the time in effect at the prime meridian not adjusted for daylight saving time.
Put together, the Date.toISOString() method will return the UTC form of an ISO8601 formatted timestamp, such as 2013-09-20T01:23:45Z. The Z at the end indicates that the time is in UTC.
But a value such as 2013-09-20 is still ISO formatted - it's just that it only has precision to the whole day, which means that it can't carry any time zone information.
When you use <input type="date">, the resulting value is not a Date class. It's a string containing the ISO formatted YYYY-MM-DD. You should just pass this directly to your application.
Now if what you are looking for is the full date and time, at midnight in the local time zone, of the date selected, and adjusted to UTC, well that's a different story. It is certainly doable but you have to understand that it is not the same as just passing the calendar date.
The easiest way to do that would be with moment.js as follows:
var s = "2013-09-20"; // from your input's value property
var m = moment(s);
var result = m.toISOString(); // "2013-09-20T07:00:00.000Z"
The value is adjusted because my time zone offset is -07:00.
You can do it without moment, but you have to replace dashes with slashes or the original value will be interpreted as if it is already in UTC.
new Date(s.replace('-','/')).toISOString()
I'm scraping a site, and the dates come in two forms:
11-22-2011 07:41 AM
Today # 07:41 AM
Both of these are GMT-8. I'd like to get a unix timestamp out of these, so that I can construct a meaningful date object
Any idea what timezone this might be? Around a month ago, the site was gibing GMT-9 times. Can javascript handle Daylight Saving Time automatically?
I'm having great difficultly parsing them. Part of the problem is the time zone.
At the moment, I'm using Date.js' parseExact:
date = Date.parseExact(date + ' PDT', 'MM-dd-yyyy H:mm tt zzz');
Hovever, this seems to get parse 12AM as 12:00, not 0:00. Additionally, I'm at a total loss as to how to handle the ones starting with today #.
When I try both of your examples using the interactive parser at http://www.datejs.com/ I get the expected results.
The timezone in question is likely "US West Coast", aka "Pacific Time".
Unfortunately that means different things at different times of the year. In the spring and summer that timezone is called "PDT" (GMT-0700) and the rest of the time it's called "PST" (GMT-0800).
To further complicate matters the dates on which that changes aren't the same as the dates on which other zones (e.g. in Europe) change.
I don't think there's a way of specifying a timezone value to Date.js that can take that into account automatically.
You could write your own, timezone-aware date parsing logic which takes into account the timezone of the remote server.
pseudo-code:
if date starts with "Today #"
replace "Today #" with currentDateInRemoteTimezone in date
endif
parse_timezone-aware(date)
Why not just add HHHH:mm zzz to get 12:00?
Use a lowercase h for the hour to get 1-12. The uppercase H gives 0-23. From your examples I would use a format of
MM-dd-yyyy hh:mm tt
Documentation
You should handle "Today # " separately. When you find that string, expect the next token to be a time in the form hh:mm tt. Parse the second part as a time and combine it with today's (local) date. That is not hard to do programmatically with Date.js functions, but you won't find a single format string that captures the "Today #" part (as you know).