I'm making booking software for a live show. My performers often send me multiple dates that they're available. I'm dealing with lots of performers and lots of dates where there could be conflicting bookings. I want the app to be able to look at all the dates and find all the conflicts.
I would love it if I could copy and paste their email text into a form field and have jquery find the dates to process them. Is there an existing system for doing this? It would have to be smart. Here are some examples of emails I recieve and the arrays I would like returned from javascript...
I can do: Aug. 29, 2018 Sep. 5, 2018 Sep. 19, 2018
{"2018-08-29","2018-09-05","2018-09-19"}
I'm available 10/9 and 11/2
{"2018-10-09","2018-11-02"}
How about Sept 8 & 15?
{"2018-09-08","2018-09-15"}
Can we do next wednesday and Nov 9?
{"2018-08-29","2018-11-09"}
You formats are way to "open" so finding something that would work for all of these would be tricky. You could look into https://dateparser.io/. They seem to support a wide range of cases as you can see here.
Some examples:
December 15th, 2010, 15th of December, 2010-12-15 ...
Also relative dates:
last friday, today, a day from now etc.
Related
It looks like Safari's implementation of Int.DateTimeFormat assumes that the second Sunday in March will ALWAYS be the DST time cutoff which is not correct as prior to 2007 it was the first Sunday in April. It also appears that this affects the other end as well when DST ends. PS: This code is being run in Indiana, USA which is in the eastern time zone (GMT-4)
More specifically...
2007 and newer: correctly for all dates.
2006: incorrectly for dates between the second Sunday in March and first Sunday in April, and between the last Sunday in October and the first Sunday in November.
2005 and older: incorrectly for all dates between the second Sunday in March and first Sunday in November.
Here's a little JSBin that outlines the exact dates where this becomes an issue (note it all works correctly on every browser but safari)
https://jsbin.com/mayadehowu/edit?js,output
var formatter = new Intl.DateTimeFormat('en');
var date = new Date('6/2/2005');
console.log(formatter.format(date)); // => outputs "6/1/2005"
I dug in further and it may be due to this change in the ECMA specifications.
ES5.1 https://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.8 "whether daylight saving time would have been in effect if the current daylight saving time algorithm had been used at the time"
ES6 https://www.ecma-international.org/ecma-262/6.0/#sec-daylight-saving-time-adjustment "An implementation of ECMAScript is expected to make its best effort to determine the local daylight saving time adjustment. NOTE It is recommended that implementations use the time zone information of the IANA Time Zone Database"
Has anyone else encountered this problem? If so what were your solutions to work around this? I need a fix, but I am skeptical to patch over a safari-specific bug by adding an hour in specific cases because if Safari fixes this then our logic will be broken again.
This was finally fixed in Safari 14.1 per #NathanQ's comment
I am working on a very small JavaScript library that allows users to retrieve content based on date. For this content, the date is just an identifier and timezones are completely irrelevant (think along the lines of a Dilbert flip calendar). The "May 14th" content is the same whether you are in the United States or Australia.
The function for retrieving data currently takes a Date object as a parameter. Within the function, the timezone is ignored. Does this approach make sense, or would it be better to take a timezone-independent identifier (like 2012-01-01) as a parameter instead? With the Date object approach, do I run the risk of returning the wrong data as a result of timezone adjustments browsers make?
How about using Date.getUTC*() functions? UTC time is the same for everyone.
After doing some research, it appears that simply ignoring the timezone information is the best approach. Why? This will always preserve the date and time that were provided to the Date constructor (which is my goal), whereas the getUTC* methods will return altered versions of the date and time. For example, take a look at this node REPL session I ran on a computer in the Eastern Time zone.
> d = new Date(2013, 03, 27, 23, 00, 00)
Sat Apr 27 2013 23:00:00 GMT-0400 (EDT)
> d.getDate() // The same date provided in the constructor. Woo!
27
> d.getUTCDate() // A different date. Boo!
28
Long story short, if you want to read the exact date and time that were provided in the Date constructor, using the normal get* methods (like getDate) will do that. If you use the getUTC* methods (like getUTCDate) modified versions of the date and time will be returned.
I know this may sound rudimentary to some of the more experienced programmers out there, but this really helped me make sense of things. I hope it helps others who come along.
The only problem with the approach in your own answer is that it doesn't account for ambiguous times. This happens during daylight savings fall-back transitions.
For example, set your computer's time zone to US Mountain Time ("Mountain Time (US & Canada)" on windows, or "America/Denver" on mac/linux). Then restart your browser and run the following javascript:
var dt = new Date(2013,10,3,1,0);
alert(dt);
This is November 3rd, 2013 at 1:00 AM. But you don't know which 1:00 AM it is representing. Is it in Mountain Daylight Time (UTC-6) before the transition, or Mountain Standard Time (UTC-7) after? There's no way to tell, and JavaScript will just use the standard time.
Now if all you need is 2013-11-03 01:00 - then you are correct. You can just ignore the offset and be done with it. But if you are going to use that value for anything meaningful - such as recording a point in time, or subtracting from another point in time for duration between them, then you have a problem that you can't resolve without the offset.
Unfortunately, there is no great solution for this problem in JavaScript. The closest thing is Moment.js, but it is still not perfect yet. Still, it is better than the Date object by itself, because it gets around browser inconsistencies and provides better parsing and formatting.
I am trying to extract different date formats from a text and later compare those dates if they belong in some time span. Let' say time span is from 1.1.2013 to 1.3.2013 . This is DD/MM/YYYY time format.
Now how can I extract different time formats from text. I have here examples of time formats.
Tue Oct 23, 2012 7:59 am
February 19th, 2013, 07:32 PM
Today, 09:22 PM
Yesterday, 09:03 AM
28 February 2013 09:38
Yesterday 16:48
8 Oct 2012 5:41:00 AM
02-18-2013, 03:17 PM
02-01-13, 12:31 PM
12.2.2013 20:43
I understand this is not a simple task to perform but any kind of suggestion can help me.
Also I am aware of this question and answers . This will benefit me later
Compare two dates with JavaScript
Also the guys on chat had this to say.
Uwe Günther
#IceD looks like you need some lib who implements that all :-)
But ih ave noe clue which one does. Better ask the Stack
IMPORTANT
I don't want jQuery in this since I can't implement it in what I am using right now. So only JS solutions for this.
You will need to normalize them to a common, comparable format, most suitably Date objects.
For some of your formats, (some browsers) will be able to Date.parse them, but for others (like "yesterday") you need to do more sophisticated parsing (up to NLP?). It would be best if you knew the format of each snippet so you can pass them to the right parsing algorithm, if not you'll need to apply some heuristics.
Merged with internationalization of dates on the web.
does anyone have any good "architecture" for the internationalization of dates? like in english its Monday, chinese: 星期一, dutch: mandaag, jap: 月曜日
So my first idea is to create some sort of class that stores the strings of Monday to Sunday in 59 different languages. Apparently this isn't scalable at all, imagine now I need to display "12:34 A.M, Monday, 1st Jan 2000" i will then need another translation for A.M, P.M, the months (both long and short forms), the ordinals, etc, etc.
It's too much work, what's the solution?
Has someone validated date of this format
Feb 9, 2010 12:07 PM
in javascript previously.There is a problem with javascript Date object its accepting Feb 9,2010 00:07 PM as a valid date.
If you fancy using a library, date.js is designed to handle this sort of situation.
Meridiem has its roots in Latin meaning noon or midday. So saying 00:07 PM, or in other words 7 minutes past noon is technically correct though not commonly used.
On the other hand, saying 12 PM is then incorrect as it means 12 hours past noon, or midnight.
So I guess it's more convention than anything, but 00:07 PM is indeed correct. Also, testing on Chrome correctly flags values over 12, such as 13:07 PM as an invalid date.
You might find this section on Confusion at noon and midnight in a 12 hour clock useful.
The behavior of the Date constructor is unspecified, so even if you can explain this behavior, you cannot rely on it working the same way across other browsers. If you want reliable behavior, you should use a library like datejs or dojo.
00 PM is noon. Seems fine to me. It won't accept any hours >12 when using AM/PM so it appears to be intended.