Date() constructor does not support seemingly valid inputs #72

Open
powdahound opened this Issue Aug 13, 2010 · 0 comments

Comments

Projects
None yet
1 participant
@powdahound

The Date() object can't be passed strings like "YYYY-MM-DD" or "YYYY-MM-DD HH:MM:SS" even though they appear valid. The resulting value will always end up as a 0. Since this is a Rhino limitation, couchdb-lucene should provide a different method for letting people work with date strings.

More info in the IRC transcript:

3:17:05 PM rnewson: but sort_order is zero for new Date(\"2010-05-14\") or anything.
3:17:08 PM rnewson: yeah.
3:17:17 PM powdahound: so now we're on the same page :)
3:17:20 PM rnewson: fascinating. thank goodness it's a real bug.
3:17:30 PM powdahound: haha yeah
3:18:58 PM rnewson: should be easy to track down now I see it in my ide
3:19:04 PM rnewson: thanks for your patience.
3:19:13 PM powdahound: I was going to add logging to toDate() in FieldType.java but didn't know how to get a logger object there :p
3:19:27 PM powdahound: no problem - thanks for not just assuming i was crazy :)
3:21:31 PM rnewson: wow.
3:21:36 PM rnewson: Context.jsToJava(args[0], Date.class);
3:21:44 PM rnewson: returns a date with 0 for that NativeDate from Rhino.
3:21:50 PM rnewson: Rhino bug? That's pretty awful.
3:22:24 PM powdahound: weak
3:22:35 PM rnewson: it seems to do this: ((NativeDate)value).getJSTimeValue();
3:22:40 PM rnewson: internally
3:23:05 PM rnewson: ahh
3:23:17 PM rnewson: / XXX: This will replace NaN by 0
3:23:21 PM powdahound: is it angry about a timezone or something special like that?
3:23:36 PM rnewson: my guess is that it would really be NaN but it's coerced to 0 for Java
3:23:39 PM powdahound: well how'd we get a NaN?
3:23:45 PM rnewson: not sure.
3:23:54 PM powdahound: i've written a lot of javascript and have always created dates that way
3:24:14 PM powdahound: at least in browsers...
3:25:42 PM rnewson: yep. I tweaked the test. 
3:25:58 PM rnewson: new Date("yyyy-mm-dd") returns zero for every date I've tried.
3:26:30 PM powdahound: "yyyy-mm-dd hh:mm:ss" fails too
3:27:01 PM rnewson: gets the right answer for new Date(2010,8,13)
3:27:38 PM powdahound: cool
3:28:38 PM rnewson: I updated the test that shows that, at least.
3:28:48 PM powdahound: rnewson: creating them that way fixes the same issue in couchdb views too (although its not using rhino…)
3:28:58 PM rnewson: interesting.
3:29:11 PM rnewson: so neither spidermonkey or rhino like that then.
3:29:18 PM powdahound: v8 is cool with it
3:29:23 PM rnewson: yeah
3:29:31 PM rnewson: I tested it in node repl also
3:29:46 PM powdahound: firefox uses spidermonkey and it works there
3:29:51 PM powdahound: doesn't it?
3:29:57 PM rnewson: no idea.
3:30:16 PM powdahound: yeah it does
3:30:42 PM rnewson: well, I'm stumped. it's not c-l, at least.
3:31:21 PM powdahound: Date.parse("2010-08-13") also doesn't work and I'm pretty sure that's supposed to return a Date object also
3:31:49 PM rnewson: right but if it only works for certain patterns and returns NaN for invalid ones, that would explain both things.
3:32:10 PM rnewson: c-l understands a few date formats, perhaps just use that?
3:32:32 PM powdahound: but its not just different patterns, it's single string arg vs multiple ints
3:32:55 PM powdahound: i'm definitely OK passing it in split up like that but it'd be nice to put something in place so others don't get burned by this
3:32:56 PM rnewson: well, the ints require no parsing, so I can see that would work
3:33:02 PM powdahound: and it is strange that Date.parse() doesn't work
3:33:39 PM rnewson: this is 1.7R2 of rhino, checking for updates
3:34:24 PM rnewson: that's the latest.
3:38:09 PM rnewson: https://bugzilla.mozilla.org/show_bug.cgi?id=586268
3:38:37 PM powdahound: neat
3:39:22 PM powdahound: c-l should probably throw warnings in these cases?
3:40:45 PM rnewson: how will it know? this is internal to rhino.
3:40:53 PM rnewson: 0 is a legitimate value for a date :(
3:41:08 PM powdahound: hmm true
3:41:53 PM powdahound: i guess the first time c-l sees the result its too late to be able to detect any misuse
3:43:14 PM rnewson: I'd use the built-in javascript engine in jdk6 if Apple hadn't replaced it with their own scripting language on OS X.
3:43:29 PM rnewson: but I think it's probably a fork of rhino anyway
3:45:33 PM powdahound: looks like my sort_order values are in microseconds when using Date() objects
3:46:34 PM powdahound: maybe i'll just stick with the strings - definitely less code than building date objects turned out to be
3:46:44 PM powdahound: var date_obj = new Date(parts[0], parts[1], parts[2], parts[3], parts[4], parts[5]); :(
3:47:40 PM rnewson: c-l parses the strings itself and should error if you pass a non-matching one.
3:47:48 PM rnewson: perhaps I should remove the Date object support?
3:48:17 PM powdahound: it's certainly tricky right now
3:48:34 PM powdahound: what if you have a special field type for date where it expects a certain format?
3:49:30 PM rnewson: new Date(\"January 6, 1972 16:05:00\"), works fine
3:49:54 PM rnewson: hm, perhaps an enhancement where you can pass the date parsing pattern?
3:50:41 PM powdahound: all comes down to simplicity vs power :)
3:51:52 PM rnewson: well, we've tracked it down and found the cause.
3:52:09 PM powdahound: always better than walking away
3:52:21 PM rnewson: I think being able to do {"type":"date","date_pattern":"YYYY-MM-DD"} would be neat.
3:52:29 PM powdahound: even if nothing is changed now I think a warning in the README would be nice
3:52:29 PM powdahound: yeah
3:52:56 PM rnewson: could you file an issue for this specific bug?
3:53:03 PM rnewson: I'm too tired to fix it, it's midnight.
3:53:17 PM powdahound: yeah i'll add a ticket. thanks for your help
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment