In IE if you write in the console new Date("22/22/22") you get the answer of Mon Oct 22 00:00:00 CDT 1923
In Chrome it says Invalid Date.
What is happening here and why?
What is happening here and why?
What's happening is you're running into undocumented behavior. The only string format the Date constructor is required to support is the ISO-8601 simplification in the specification, which your example does not match. Everything else is undocumented and JavaScript engines are at liberty to do whatever they want, including guessing at the format you're giving them (and doing JavaScript's nifty rollover when you take a value like 'month number' out of bounds), or giving you an invalid date.
If you're curious about the rollover, IE's treating that as the 22nd day of the 22nd month of the year 1922. Naturally, years don't have 22 months, but JavaScript's Date is defined as handling rollover in various fields, such as month number, gracefully. So the 22nd month of 1922 is actually the 10th month of 1923, and of course, you're on the 22nd day of it: October 22, 1923.
IE 11 and Firefox 42 translates the value 22 for month to 12+10.
Chromium throws a error.
Different JS engine implementations gives different results for invalid values.
Related
I am using the DateTime-local in the HTML field to obtain the datetime from the users. I am sending the same to the backend which I am using to create the XML file. When I send the date to backend it subtracts itself by 2 hours for some reason.
I am not making any changes to it. I am currently in Central European Time (CET), I am guessing its changing automatically to UTC time because CET is 2 hours ahead of UTC. I am just curious to know whats happening here.
I am using the HTML, AngularJS and Nodejs for my project and following are my code samples:
HTML:
<input type="datetime-local" class="form-control" ng-model="formdata.EventTime">
For example, if I selected: 08 October 2020 12:30 PM then after the selection the field would appear something like this: 08/10/2020 12:30
In the AngularJS, just before making the HTTP POST request to my NODE.js I tried to console.log the time and it appeared something like this:
Thu Oct 08 2020 12:30:00 GMT+0200 (Central European Summer Time)
Now finally when I console.log in my Node.js then it appears something like this:
2020-10-08T10:30:00.000Z
I am just curious to know if this is some default functionality?
I could not find similar questions elsewhere so I am posting this.
There's a simple enough reason for the difference. The outputs of both are showing the same instant in time, however the AngularJS log is formatting the date in RFC 2822 format which shows the local timezone, while Node.js is logging the time in UTC formatted as an ISO 8601 time.
If you do this in both AngularJS and Node.js:
console.log(date.toISOString());
You'll get the same output (e.g.)
2020-10-08T10:30:00.000Z
Likewise if you try
console.log(date.toString());
You should get a similar output but in RFC 2822 format (e.g.)
Thu Oct 08 2020 12:30:00 GMT+0200 (Central European Summer Time)
Thanks, #Terry for the response. Based on his answer I did the following, I used the moment to convert my time from UTC to local. My project required me to retain the format of the date and syntax of it.
Install the moment library in Node.js.
When I was selecting 08/10/2020 15:30 in the datetime-local I was getting following date in Node.js:
2020-10-08T13:30:00.000Z
I tried converting it using:
EventTime = moment.utc(EventTime).local().format('YYYY-MM-DDTHH:mm:SS.sss');
Finally I got following output:
2020-10-08T15:30:00.000
I hope if someone else has the same doubt this might help.
I have a problem with the date function in visualforce.
My code looks as following:
<apex:outputText value="{0, date, DD MMMM YYYY}">
<apex:param value="{!Opportunity.Invoice_Due_Date__c}" /> </apex:outputText>
Invoice_Due_Date__c is a simple datepicker with no specific rules.
Everytime a date is selected month and year are shown correctly, but day always has numbers higher than 150, which makes absolutly no sense.
Do I have to change the code or the settings of the custom field?
Visualforce follows Java's "simple date format" rules. <apex:outputText> documentation has example of yyyy.MM.dd rendering to 2004.11.20.
Capital D means day-in-year, 1 to 366 range :)
Pay attention to capital Y too, you want it lowercase. Uppercase one is used in some tricky reporting like if you have factory/warehouse/accounting team insisting new year doesn't always start on January 1st. Sometimes they'll swear to you July started on June 29th ;) Crazy people
I know that Gregorian calendar started on Oct 15th 1582, and during the transition from Julian calendar, 10 days had been dropped.
When I'm doing this query:
SELECT STR_TO_DATE('1582-10-05', '%Y-%m-%d')
I'm getting this result:
1582-10-15 (the 10 days difference).
But when I'm trying to match between such dates I'm getting the original date (Oct 5th and not 15th).
For example:
SELECT STR_TO_DATE('1582-10-05', '%Y-%m-%d') = STR_TO_DATE('1582-10-15', '%Y-%m-%d')
I'm getting a false response, although you would have expected to get a true since Oct 5th actually count as Oct 15th, as we saw in the first example.
Anyone can explain what's going on here?
On documentation it is stated that, TO_DAYS and FROM_DAYS functions must be called cautiously because of the transformation you noticed. Additionally, when I inspect the source codes of MySQL, I realized that STR_TO_DATE uses similar methodology with these functions. As I understand, cutover dates are completely unsafe to store or apply operations. Documentation says; "Dates during a cutover are nonexistent.", too.
Also for the inconsistency between different servers I may have an explanation. I have 2 different machines which have MySQL installed in Istanbul, Turkey and Frankfurt, Germany. They have same setup excluding localisation settings. First one shows 1, the other one shows 11 for the date substraction query. It means (in my humble opinion) there is unexplained sections about calendar cutover & localisation on official documentation.
Please see the following results:
SELECT STR_TO_DATE('1582-10-05', '%Y-%m-%d');
# Result #1: 1582-10-15
SELECT DATE_FORMAT(STR_TO_DATE('1582-10-05', '%Y-%m-%d'), '%Y-%m-%d');
# Result #2: 1582-10-05
SELECT DATE_FORMAT(STR_TO_DATE('1582-10-15', '%Y-%m-%d'), '%Y-%m-%d');
# Result #3: 1582-10-15
SQL fiddle demo.
These indicate the problem lies in the way the 1582-10-05 date is displayed rather than how it is stored. Result #2 shows that if the DATE_FORMAT function is used instead to explicitly convert the date into the same string format then the input date is displayed. This also explains why the comparison query in the question returns false: Behind the scenes, the two stored dates are different.
As you've discovered, this quirk occurs for all dates between 1582-10-05 and 1582-10-14 inclusive, i.e. the range of dates that don't really exist: The implicit conversion to text for all of these gives a date 10 days after. So if for some reason there is a need to display dates in this range (perhaps questionable), a simple workaround is to always use the DATE_FORMAT function.
I'm have access to a 3rd party application's database, and I see a field called "date" which stores date/time values as floating point numbers, but I'm not sure how this floating point number is mapped to a date/time. There is no documentation for this database.
Here is some sample data:
date-field actual-date-time
253507382.168744 1/12/09 6:43 PM PST
253507480.136126 1/12/09 6:44 PM PST
253508091.838982 1/12/09 6:54 PM PST
256703604.015055 2/18/09 6:33 PM PST
256704413.484674 2/18/09 6:46 PM PST
Note: I had to enter these values manually so there's a slight chance they may be off a bit. If you would like to see more data, let me know and I'll add more.
I'm hoping someone is familiar with storing dates in this format and can let me know how to get a date/time given a floating point number.
If you look at the change in the numbers over the 10 and 13 minute intervals, you'll see that it's about 60. Therefore I conclude that it's a count of the number of seconds from a base date.
I think the base date is 1/1/2000 or 1/1/2001.
Edit: The base date appears to be 1/1/2001, and the time appears to be adjusted as well - it's probably UTC with your local time offset added.
If you subtract any of the two points you'll see that the values represent the number of seconds, at microsecond accuracy. It should be easy to work out the base date where the clock "started". On Unix and related systems this is January 1st, 1970.
The timestamps are 'number of seconds elapsed since 00:00 on January 1st 2001'. It's not a common date format but at least it should be easy to work with now you know what it represents!
Examples:
'DD/MM/YYYY
"1/1/2009" should give `1`
"31/1/2009" should give `5`
"1/2/2009" should also give `5`
Format("1/2/2009", "ww") returns 6.
So, how can I get the correct result?
It's doing two things here which don't match your expectations, I think:
Assuming you want the week with Jan 1 in as week 1, and using Sunday as first day of the week
So it has week 1 running from Sunday 28th December 2008 to Saturday 3rd Jan 2009.
Week 6 would begin on Sunday 1st Feb by this method.
The ISO standard is for week 1 to be the one containing 4 days of January, or the first Thursday of the year (different ways of expressing the same thing).
You can specify this method of calculation and the first day of the week:
Format(SomeDate,"ww",vbMonday,vbFirstFourDays)
see here for syntax:
https://support.office.com/en-US/article/Format-Function-6F29D87B-8761-408D-81D3-63B9CD842530
Regardless of the day of the week your week starts on, you need to pass unambiguous date values. "31/1/2009" can only be one date (Jan 31st), but "1/2/2009" could be Jan. 2 (US style) or Feb. 1st (everybody else who has more sense that we USAns).
In this case, I'd use DateSerial() to make sure the date is not misinterpreted:
Format(DateSerial(2009,2,1), "ww", vbMonday)
While this is not causing your problem, because Access helpfully utilizes your system's localized date settings, I think it's something you should do anyway. You certainly are forced to do so in SQL in Access, so I don't think it's a bad habit in code and expressions.
This might work: Format(YourDate, "ww",vbMonday)
"Correct result" depends on the locale. Maybe VBA will let you pick a calendar-system, otherwise you're pretty much out of luck.
Note that First-Day-On-xxDay isn't your only problem. There is also variation on what a complete week is so Week 1 in one system could be Week 53 of the previous year in another system.
So test thoroughly and don't be seduced to "correct by 1".
There is a whole standard for week numbers: ISO-8601
http://en.wikipedia.org/wiki/ISO_8601#Week_dates
I had the same problem.
It showed week 53 and week 1, yet days in week 53 and week 1 are all in week 1
I first tried changing the date format in the Access Query to this:
OrderWeek: Format([OrderDate],"yyyy-ww",1,3) <-- But it did not do the trick.
You get dates like 2014-52 for week 52 and 2015-52 where it was week 1 before.
Also the sorting was not how I liked. It sorted the data as 2014-1, 2014-11, 2014-2 etc. I want it to show as 2014-01, 2014-02 .. 2014-11 etc.
So here is the new code to display both the year and the week correctly in an Access Query:
ActualWeek: IIf(DatePart("ww",[SomeDate])=53,DatePart("yyyy",[SomeDate])+1,DatePart("yyyy",[SomeDate])) & "-" & IIf(DatePart("ww",[SomeDate])=53,"01",IIf(DatePart("ww",[SomeDate])<10,"0" & DatePart("ww",[SomeDate]),DatePart("ww",[SomeDate])))
This now shows any days from week 53 as being part of week 1
If sunday is the first day of the week (as it is in some locales) then 6 is the correct weeknumber for "1/2/2009" (february 1. 2009)
In terms of the sorting, I had the same issue and used this code to resolve it:
IIf(Format([SomeDate],"ww")<10,Format([SomeDate],"yyyy-") & "0" & Format([SomeDate],"ww"),Format([SomeDate],"yyyy-ww"))
If the week number is less than 10, add a zero, else leave it as is.
Now the sorting is fine. Hope this helps somebody.