| 00:03 | <MikeSmith> | Hixie: would it be useful for the spec to suggest a convention for the file extension for application-cache manifest files/ |
| 00:03 | <Hixie> | that goes in the mime type registration bit |
| 00:04 | <MikeSmith> | Hixie: that's not been written yet? |
| 00:08 | <Hixie> | not yet |
| 00:08 | <Hixie> | sometime this year |
| 00:10 | <MikeSmith> | k |
| 01:21 | <billyjackass> | Hixie: is there any way I can programatically examine the URLs lists from an appcache manifest file? |
| 01:22 | <billyjackass> | I'm trying to figure out how to write a test to see whether the application cache is actually working as expected |
| 01:26 | <Hixie> | MikeSmith: not from within the browser, no |
| 01:26 | <Hixie> | i mean you can xhr it and parse it yourself |
| 01:27 | <MikeSmith> | yeah |
| 01:29 | <MikeSmith> | Hixie: so lacking that, I'm wondering how one could write a test to see whether the UA actually conforms to the spec |
| 01:31 | <MikeSmith> | hmm, does Safari really not have a "Work Offline" option? FF and Opera both do |
| 01:31 | <Hixie> | why? as a tester, you know what's in the manifest |
| 01:31 | <Hixie> | just pull the plug and see if the urls keep working |
| 01:31 | <Hixie> | afk, food |
| 01:36 | <roc> | MikeSmith: https://developer.mozilla.org/en/DOM/window.navigator.mozIsLocallyAvailable |
| 01:38 | MikeSmith | looks at roc link |
| 01:38 | <MikeSmith> | roc: ah, excellent |
| 01:38 | <MikeSmith> | thanks |
| 01:40 | <roc> | we proposed that for the spec but people felt it wasn't important enough |
| 01:43 | <Hixie> | mozIsLocallyAvailable doesn't tell you what's in the manifest |
| 01:43 | <Hixie> | it tells you what's cached |
| 01:44 | <Hixie> | and wouldn't really help with testing what's cached, since you can't trust what the browser tells you in a test :-) |
| 01:44 | <roc> | that's true, but I think it's what he actually wants |
| 01:47 | <roc> | MikeSmith: btw for your tests you probably want to flush the main browser cache before you run the test because otherwise mozIsLocallyAvailable (or manual URI loads, for that matter) could be served out of the main cache |
| 01:48 | <MikeSmith> | roc: OK |
| 02:06 | <MikeSmith> | http://hg.mozilla.org/mozilla-central/rev/fbbc3d6c9f3171023ab94d286e9c4bea80f1ef22 |
| 02:06 | <MikeSmith> | tracemonkey wasn't in mozilla-central previously? |
| 02:08 | <roc> | no, it was, that's just an update from the tracemonkey repo to the mozilla-central repo |
| 02:08 | <roc> | they've continued to use a parallel repository |
| 02:08 | <roc> | the wonders of DVCS |
| 02:09 | <MikeSmith> | ah, I see |
| 03:00 | <jwalden> | parallel repo with periodic merges is actually pretty good for not competing too hard for a place to commit patches |
| 03:00 | <jwalden> | I have five or six people to race, not fifty or a hundred |
| 04:21 | gsnedders | stetches |
| 04:22 | <gsnedders> | I need to stop sleeping such fucked up hours. |
| 04:52 | <MikeSmith> | jwalden: how is success at getting patches committed to a particular repository affected by how many people use the repository? |
| 04:53 | <jwalden> | MikeSmith: someone screws up and pushes a patch that breaks the build or breaks automated tests, you have to wait for them to have taken steps to demonstrate that it's probably fixed |
| 04:53 | <jwalden> | fewer people means fewer times that has to happen |
| 04:53 | <MikeSmith> | jwalden: ah, I see |
| 04:54 | <jwalden> | not to mention fewer times you have to update a push to make sure you're changing tip and not committing new heads |
| 04:54 | <jwalden> | which Mozilla forbids, so if two people try at once, one will succeed and the other will have to modify the patch to sit atop the first one |
| 04:55 | <MikeSmith> | yeah, understood |
| 04:55 | <jwalden> | MikeSmith: I assume a server-side script to count times-loaded is a no-go for manifest testing? |
| 04:56 | <MikeSmith> | jwalden: It would be fine I guess. but I do really that Web developers will also end up wanting some access to it from some client-side interface |
| 04:56 | <MikeSmith> | do really think |
| 04:57 | <MikeSmith> | jwalden: as far as the part about breaking builds and tests, you guys really seem to do a lot of reverting due to that |
| 04:57 | <MikeSmith> | it seems like commits get reverted just about as often as they don7t |
| 04:57 | <jwalden> | not quite that bad, but our tests are not quite as reliable as they should be |
| 04:58 | <MikeSmith> | OK |
| 04:58 | <jwalden> | but people do make changes which break tests in will-always-happen ways |
| 04:58 | <jwalden> | not often, but it's not quite rare, either |
| 04:59 | <roc> | that's the point of having a lot of tests |
| 04:59 | <roc> | although it's better if you can run the tests locally, that's not always feasible |
| 04:59 | <roc> | getting more feasible since we'll have try-servers running tests soon |
| 05:00 | <MikeSmith> | yeah, the try-server thing is great |
| 05:00 | <MikeSmith> | I notice that's what hsivonen is using for his parser work |
| 05:01 | <MikeSmith> | I guess he's got the tests worked into that |
| 05:01 | <roc> | jwalden: we have a secret weapon against random test failures in the works ... but I'll let cpearce brag about it when it's ready |
| 05:01 | <jwalden> | gsnedders: wait for college, particularly if you're in a dorm that's not full of buckle-down-and-study people :-) |
| 05:02 | <jwalden> | roc: that's just mean, telling but not telling me |
| 05:02 | <roc> | yeah it is |
| 05:02 | jwalden | wants ops in some shared channel to enact violence upon roc |
| 05:10 | <gsnedders> | Compare: http://stuff.gsnedders.com/Overview.out.out.html and http://dev.w3.org/csswg/css3-namespace/ |
| 05:12 | <gsnedders> | (The former has never been through the module post-processor, blatantly) |
| 05:17 | <sayrer> | somehow I suspect roc's weapon concerns replay |
| 06:56 | <hsivonen> | MikeSmith: actually, I don't have tests integrated to try server pushes. The builds crash on try server and I think I know the stack of the crash but I have no idea how to fix it. |
| 06:58 | <MikeSmith> | hsivonen: the builds crash right away at some smoke-testing stage? |
| 06:58 | <hsivonen> | MikeSmith: right. |
| 06:59 | <hsivonen> | MikeSmith: I can't reproduce on Mac. I can on Linux. |
| 06:59 | <hsivonen> | MikeSmith: on Linux, the first run after a fresh compile (even with and old profile) crashes |
| 06:59 | <hsivonen> | the second run doesn't |
| 06:59 | <hsivonen> | it's weird |
| 06:59 | <MikeSmith> | heh |
| 07:00 | <hsivonen> | moreover, the stack trace doesn't show local variables for the interesting bits |
| 07:00 | <MikeSmith> | ah |
| 07:00 | <MikeSmith> | well, makes it kind of hard to debug I guess |
| 07:00 | <hsivonen> | but it's related to freeing interned strings that are alive through the process lifetime |
| 07:01 | <hsivonen> | my guess is that there's a bug when the same string has been interned from two atom tables, although I've been told that's OK |
| 07:02 | <MikeSmith> | hsivonen: would that be something a lint checker or some other kind of static analysis thing might find for you? |
| 07:02 | <hsivonen> | I think that would be unlikely. |
| 07:02 | <MikeSmith> | OK |
| 08:28 | <hsivonen> | grr. read-only google spreadsheets inhibits my ability to copy text |
| 10:17 | Lachy | wonders how many people, out of those arguing for better historical date and alternative calendar support in the <time> element, would actually make use of such historical dates and alternative calendars themselves. |
| 10:18 | <Lachy> | I suspect this is another case of people arguing to support use cases for other people, when those other people aren't really calling for such use cases to be addressed by HTML |
| 10:24 | <hsivonen> | Lachy: and more importantly, who'd actually consume the data without a prior bilateral agreement |
| 10:25 | <Lachy> | indeed |
| 10:26 | <Lachy> | the only potentially compelling use cases I've seen in that thread relate to imprecise dates, like YYYY or YYYY-MM. |
| 10:26 | <Lachy> | although, they still need more investigation into the problems being solved |
| 10:31 | <hsivonen> | that would only make approximate sense for Julian years |
| 10:31 | <hsivonen> | but would still distriminate against various calendars still in religious use |
| 10:33 | <Lachy> | what? The use cases I was referring to for imprecise dates have nothing to do with julian dates |
| 10:33 | <Lachy> | nor any other non-Gregorian calendars |
| 10:34 | <roc> | just use timestamps which are unlimited-precision floating point numbers of seconds since the Unix epoch, with negative values allowed |
| 10:39 | <hsivonen> | Lachy: oh ok. |
| 10:40 | <hsivonen> | s/distriminate/discriminate/ |
| 10:44 | <Philip`> | roc: Unlimited precision doesn't help when I want to represent the moment precisely a third of a second after the epoch |
| 10:45 | <roc> | will you settle for rational numbers or do we need full support for transcendentals? |
| 10:46 | <annevk5> | wasn't <time> also meant to replace class=date kind of stuff? e.g. as styling hook |
| 10:46 | <annevk5> | in that case it sort of makes sense to allow just years or months |
| 10:47 | <Philip`> | roc: It's possible that we'll be invaded by aliens whose calendar systems use multiples of pi seconds, so we'd better make sure HTML can cope with that use case |
| 10:47 | <Philip`> | or perhaps we should just use RDFa for it |
| 12:11 | <hsivonen> | looking at http://www.w3.org/Bugs/Public/show_bug.cgi?id=6684 , could just fix text/* in non-SMTP protocols already? |
| 12:35 | <jgraham> | Crazy telecoms related things number #3456 we just got PAYG mobile broadband with 3 to fill in the gap before we can convince someone to give us proper useful broadband. To buy time you have to log onto the website. To log on to the website you need a password. They supply the password by SMS. To get the SMS you need either a 3G Phone or a Windows laptop |
| 12:35 | <jgraham> | because even though they have a OS X version of the client software it doesn't support the SMS feature |
| 12:36 | <MikeSmith> | jgraham: I recommend a shotgun. |
| 12:37 | <MikeSmith> | (for you visit to the headquarters to discuss the issue) |
| 12:37 | <jgraham> | MikeSmith: Oh, I thought you were suggesting suicide |
| 12:38 | <jgraham> | (Anyway their uselessness pales into comparison compared with tele2 who, two whole months after we first asked for a broadband connection and were told 2-3 weeks, finally decided that we had not been in the country for long enough and so were not entitled to their services) |
| 12:38 | <MikeSmith> | heh |
| 12:39 | <hsivonen> | has anyone tested if nodeName returning in upper case in WebKit for HTML elements is a characteristic of the node itself or its owner document? |
| 12:39 | <MikeSmith> | jgraham: welcome to Scandinavia |
| 12:39 | <jgraham> | MikeSmith: Indeed |
| 12:39 | <MikeSmith> | World's Best Customer Service |
| 12:40 | hsivonen | had a pretty good experience with getting IP connectivity to a new apartment |
| 12:40 | <hsivonen> | right on time |
| 12:40 | <hsivonen> | but then, it wasn't ADSL |
| 12:40 | <jgraham> | hsivonen: What was it? |
| 12:41 | <hsivonen> | jgraham: I don't know. Could be fiber optic. The pipe that comes into the apartement is 100 M Ethernet |
| 12:41 | <jgraham> | hsivonen: How much does that cost? |
| 12:43 | <hsivonen> | we only pay for 10/10 M, which is 32.90 euros per month. 100/10 M would be 42.90 euros per month |
| 12:43 | <hsivonen> | (incl. VAT) |
| 12:44 | <jgraham> | That sounds roughly similar to Sweden. I think the UK is quite a bit cheaper (or can be) |
| 12:54 | <hsivonen> | hmm. looks like HTML 5 defines the case folding to be dependent on the HTML documentedness of the document and not a property of the element nodes themselves... |
| 12:57 | <MikeSmith> | virtuelv: you calling in to widgets call? |
| 12:58 | <MikeSmith> | and any clues where is marcos? |
| 13:09 | <hsivonen> | Hixie: should script-inserted base attribute in the XML namespace be ignored in HTML documents? |
| 13:19 | <hsivonen> | Do we want to make createElement in XML documents whose document object implements the HTMLDocument interface create elements in the XHTML namespace? |
| 13:21 | <Lachy> | hsivonen, yes |
| 13:21 | <Lachy> | well, maybe |
| 13:22 | <Lachy> | what do browsers do? |
| 13:23 | <hsivonen> | Lachy: I haven't written a test case, I have only read browser source :-) |
| 13:23 | <hsivonen> | but source says yes |
| 13:23 | <hsivonen> | Gecko's source, that is |
| 13:26 | hsivonen | sees http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#6057 |
| 13:27 | <Lachy> | hsivonen, document.createElement("foo").namespaceURI returns the XHTML namespace in an XHTML document. |
| 13:28 | <hsivonen> | Lachy: excellent. thanks |
| 13:29 | <Lachy> | for an SVG document, Opera returns the SVG namespace, but Gecko and WebKit return the XHTML namespace still |
| 13:30 | <hsivonen> | Hixie: Web DOM Core doesn't have renameNode... |
| 13:30 | <hsivonen> | Hixie: but HTML 5 places a requirement on its behavior |
| 13:44 | <hsivonen> | Does SetAttributeNode really lower case the name in existing browsers? |
| 13:44 | <hsivonen> | Shouldn't instead the attribute node creator method do the lower casing? |
| 13:46 | hsivonen | files a spec bug |
| 13:50 | <Lachy> | JohnResig, yt? |
| 13:50 | <JohnResig> | Lachy: what's up |
| 13:50 | <Lachy> | JohnResig, I just noticed that the selectors api test suite doesn't contain any tests for the namespace selectors "|foo" and "*|foo", which need to be supported cause they don't need to be resolved |
| 13:51 | <JohnResig> | Lachy: so the should be handled as if they were the same as "foo", correct? |
| 13:52 | <Lachy> | "|foo" matches elements in no namesace. i.e. the element created by document.createElementNS("", "foo"); |
| 13:52 | <JohnResig> | hmm |
| 13:52 | <Lachy> | "*|foo" should match a foo element in any namespace |
| 13:53 | <Lachy> | for "|foo", you would have to test it by creating elements with createElementNS. You can't rely on any elements in an HTML document being in no namespace, since browsers (and HTML5) say to use the XHTML namespace |
| 13:55 | <Lachy> | I'll send an email about this to public-webapps as a reminder for this to be added when you have time |
| 13:55 | <JohnResig> | Lachy: ok, thanks |
| 14:05 | <Lachy> | JohnResig, I just made some quick demos and it looks like WebKit fails the "|p" test. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/27 |
| 14:05 | <Lachy> | both Opera and Firefox pass that oen |
| 14:05 | <Lachy> | *one |
| 14:05 | <Lachy> | IE8 will fail because it doesn't support the namespace syntax |
| 14:06 | <JohnResig> | Lachy: ok, definitely post it to the list then, because I'm cautious of landing changes that'll cause 100%-passing regressions (people get grumpy) |
| 14:06 | <JohnResig> | it seems painless enough to land, though |
| 14:07 | <Lachy> | JohnResig, the whole point of a test suite is to find bugs. If we can find bugs in browsers that currently pass 100%, that's even better. |
| 14:08 | <JohnResig> | Lachy: absolutely - but I don't want the burdern of notifying and arguing with the vendors to be on me - that should be on the spec people (you) |
| 14:08 | <JohnResig> | since my only rebuttle will be "Well, Lachy told me to add it." |
| 14:08 | <Lachy> | good |
| 14:09 | <JohnResig> | just let them know on the list and I'll land it no problem |
| 16:07 | <annevk> | so when of the Python devs is here and when I asked him about the annoyance that the internal encoding can be set at compile time he admitted it was a mistake and that they should have fixed it to UTF-32 |
| 16:07 | <annevk> | a small battle ensued |
| 16:08 | <annevk> | s/so when/so one/ |
| 16:08 | <smedero> | � |
| 16:08 | <Dashiva> | utf-32? heh |
| 16:09 | <annevk> | PHP6 with ETA "unknown" will be fixed to UTF-16 according to Rasmus (also here) |
| 16:10 | <Lachy> | why would anyone want to use UTF-32 for anything?! |
| 16:10 | <Philip`> | Because it's easy and works |
| 16:10 | <Philip`> | unlike everything else |
| 16:10 | <Dashiva> | If you think space is cheap and astral characters are important, I suppose |
| 16:11 | <Lachy> | but it's so inefficient with space, and UTF-16 is only mildly less efficient with non-BMP characters |
| 16:11 | <Philip`> | Lachy: With UTF-16 you can't do constant-time extraction of substrings |
| 16:11 | <gsnedders> | PHP6 just uses UTF-16 because it's what ICU uses |
| 16:11 | <Philip`> | (because you've got to scan the whole string to count characters) |
| 16:12 | <Philip`> | If you care so much about performance that a mere doubling of string sizes is significant, you shouldn't be using Python |
| 16:13 | <annevk> | gsnedders, he might have mentioned that, yes :) |
| 16:14 | <Lachy> | Philip`, that's why python shouldn't bother with UTF-32 for the small performance benefit it brings in comparisson with its overall performance |
| 16:15 | <Philip`> | Lachy: It's much more than a small performance benefit when you're e.g. extracting the millionth character from a string, and it can read the four-millionth byte instead of scanning through the whole string |
| 16:15 | <jgraham> | Lachy: Do you have evidence that most programs consume a significant amount of their memory in string types? |
| 16:16 | <Lachy> | no |
| 16:16 | <jgraham> | UTF-32 is much /much/ easier than UTF-16 for non-BMP characters |
| 16:16 | <Lachy> | Philip`, jgraham, so are you arguing that using UTF-32 for python is a good thing? |
| 16:17 | <jgraham> | Lachy: If the choice is between the UCS2 and UCS4 code currently in Python, UCS4 wins every time |
| 16:17 | <Philip`> | Lachy: It seems a better thing than the alternatives |
| 16:17 | annevk | notes that what Python does depends on how you compile it and will continue to do so for the foreseeable future in case that wasn't clear |
| 16:17 | <jgraham> | (the 2-byte string code is not quite UTF-16) |
| 16:18 | <jgraham> | (Or at least python doesn't really handle non-BMP characters well) |
| 16:18 | <gsnedders> | (Guido said on the dev mailing list that anywhere it wasn't UTF-16 was a bug) |
| 16:18 | <gsnedders> | (But it presents non-BMP characters to interpreted code in a whacky way (i.e., as surrogates)) |
| 16:20 | <Lachy> | how many people actually deal with astral characters in python programs? |
| 16:20 | jgraham | raises a hand |
| 16:20 | gsnedders | raises a hand |
| 16:21 | <Lachy> | what do you use them for? |
| 16:21 | <jgraham> | Lachy: html5lib |
| 16:21 | Philip` | raises a hand, complete with half an arm and some severed tendons |
| 16:21 | <gsnedders> | For stripping any character not valid in ifragment in Anolis when creating IDs |
| 16:21 | <jgraham> | Also some thing I did for parsing the UCD |
| 16:23 | <annevk> | http://www.christopherschmitt.com/2009/03/12/convert-xhtml-web-pages-to-html5/ has some amusing terminology |
| 16:24 | <annevk> | and untidying is fun too |
| 16:24 | jgraham | wonders why he can't reproduce a bug in the python unicode support, realises he is using a UCS4 build |
| 16:52 | <Philip`> | gsnedders: Be careful about suggesting deferring to self-proclaimed date/time experts who wrote ISO8601, because the same argument could apply to things like RDF :-p |
| 17:48 | <ap> | annevk: does the change event bubble in IE? I didn't test myself, but saw a blog post saying that it didn't (referenced in the bug) |
| 17:49 | <annevk> | dunno, but the testcase works in Opera (and reportedly Firefox) |
| 17:49 | <annevk> | maybe Hixie based the spec on IE? |
| 17:49 | <zcorpan> | Lachy: please have both "" and null in the test suite :) |
| 17:49 | <ap> | annevk: that usually makes sense ;) |
| 17:49 | <annevk> | I suppose |
| 17:50 | annevk | launches IE6 |
| 17:50 | <ap> | zcorpan: that's a CSS Selectors test, not a DOM 3 one! :) |
| 17:50 | <ap> | annevk: I'm also puzzled by the requirement to fire the event asynchronously (post a task to fire a simpl event) |
| 17:51 | <gsnedders> | :P |
| 17:51 | <annevk> | I'm mostly mystified with the event source thing so I can't help you there |
| 17:51 | <annevk> | in IE6 the onchange handler does not trigger |
| 17:52 | <gsnedders> | Philip`: There is a difference between saying that use-cases they didn't deal with we don't have to compared with we have to cope with all their use-cases. |
| 17:52 | <annevk> | but I've no idea if that means it doesn't do bubbling |
| 17:52 | <gsnedders> | Damn chaals writes long emails at times. |
| 17:52 | <ap> | annevk: the test at <http://www.johnvey.com/blog/2007/07/ie-does-not-bubble-form-select-element-onchange-events>; uses attachEvent, so it apparently doesn't bubble |
| 17:54 | <annevk> | ap, it seems that the more useful thing to do is to bubble though |
| 17:54 | <zcorpan> | ap: yeah, true |
| 17:54 | <annevk> | ap, and IE can fix bugs |
| 17:55 | <annevk> | I guess you can use capture listeners instead, but that's cumbersome |
| 17:57 | <zcorpan> | so firefox and webkit don't support 'copy' in canvas globalCompositeOperation |
| 17:57 | <annevk> | (and also doesn't work in IE :p) |
| 18:00 | <Philip`> | zcorpan: I think they do |
| 18:01 | <Philip`> | (modulo certain bugs that are not directly related to 'copy') |
| 18:48 | <gsnedders> | What's controversial about bb? |
| 18:49 | <annevk> | the name! |
| 18:49 | <Philip`> | The fact that it's a crazy idea |
| 18:50 | <smedero> | didn't Philip` find a noticeable occurrence of people mistyping b as bb. |
| 18:50 | <gsnedders> | smedero: I dunno. Ask Philip`. |
| 18:50 | <Philip`> | It's like a script API but made much harder to use by not actually being a script API |
| 18:51 | <Philip`> | Hmm, a load of people use <bb:menu> elements |
| 18:52 | <gsnedders> | LOL |
| 18:52 | <gsnedders> | "to Pillar and Hedral for their ideas and support." |
| 18:52 | gsnedders | expects they gave Hixie lots of ideas :P |
| 18:52 | <Philip`> | There do exist people who typo <b> as <bb>, but not a huge number |
| 18:53 | <Philip`> | and hopefully <bb> is specced so it does nothing if it's not got any interesting attributes |
| 18:54 | <smedero> | http://menumachine.com/kb/64 suggest that <bb:menu> is some sort of GoLive plugin? |
| 19:00 | jgraham | has somewhat crappy home internet at last |
| 20:20 | <gsnedders> | jgraham: w00t! crappy intarwebs! |
| 20:22 | <gsnedders> | jgraham: How on earth did you get that photo? |
| 20:28 | <jgraham> | gsnedders: Multiple photos overlayed |
| 20:28 | <gsnedders> | I was guessing that. |
| 20:29 | <jgraham> | Macro lens wih the minimum depth of field |
| 20:29 | <jgraham> | I really want to do it in a way that looks seamless |
| 20:31 | <jgraham> | And SSH seems to be really bad on this connection |
| 20:34 | <Philip`> | jgraham: You could make it seamless by taking a single photo :-) |
| 20:49 | <jgraham> | Philip`: Yes, if I had a large format camera :) |
| 22:55 | <jcranmer> | why are non-Gregorian dates such a big deal? |
| 22:55 | <jcranmer> | point 1: How many people are actually going to add in <time> elements for all of their dates? |
| 22:56 | <jcranmer> | point 2: How many of those people are cogniscent of the Gregorian/Julian calendar issues? |
| 22:56 | <jcranmer> | point 3: How many of those will actually care enough to do it right? |
| 22:57 | <jcranmer> | if it's that much of an issue, just make it the Hixie calendar: an integer denoting the time in days since Hixie's birthday |
| 22:58 | <jcranmer> | </rant> |
| 23:01 | <Philip`> | jcranmer: If we do that, we'll build up an entire civilisation based on offsets from Hixie's birthday, and then we'll probably find out that actually Hixie was born around four years earlier than that |
| 23:01 | <Philip`> | and then we won't be sure whether he even existed, or was just a fiction created by the WHATWG cabal |
| 23:02 | <jcranmer> | ok then, how about a better time |
| 23:02 | <jcranmer> | 1234567890 in Unix time? |
| 23:02 | <jcranmer> | February 29, 1900? |
| 23:02 | <jcranmer> | Smarch 13, 1313? |
| 23:03 | <Philip`> | January 1, 1601 |
| 23:03 | <Philip`> | in order to match Windows |
| 23:03 | <Philip`> | (http://blogs.msdn.com/oldnewthing/archive/2009/03/06/9461176.aspx) |
| 23:06 | <kig> | how about a floating point number that measures the count of planck intervals from the present time in the current frame of reference |
| 23:06 | <kig> | floating point just to be sure and present time because it simplifies calculations because the current time is always 0.0 |
| 23:07 | <Philip`> | kig: If it's Planck intervals, why not just use integers? |
| 23:09 | <kig> | future proof |
| 23:09 | <Philip`> | Are you expecting the laws of physics to change in the future? |
| 23:09 | <kig> | most certainly |
| 23:10 | <Philip`> | Hmm, I suppose it's good to make sure HTML5 is prepared for that future and won't be adding to our problems in such an eventuality |
| 23:11 | <kig> | oh, better make it a complex number, i hear they're all the rage in quantum probability |
| 23:11 | <Lachy> | kig, who's frame of reference, exactly? It would be kind of hard since everyone's frame of reference is slightly different, because it's based on how fast they're moving and slight differences in gravity |
| 23:11 | <kig> | well, the frame of reference of the author |
| 23:11 | <kig> | or rather, the document |
| 23:11 | <kig> | at the present point in time on the present device |
| 23:11 | <Philip`> | Lachy: Relative time offsets from daylight saving is hard enough, we don't want to add relativity too :-( |
| 23:14 | <kig> | and as all the times you define are relative to the document, it's super easy to say things like <time value="5*60*plank_per_sec">five minutes from now</time> (but saying 5th of march 2007 is a bit more difficult) |
| 23:14 | <Philip`> | Planck intervals from the present time are fine to add into HTML5, but we've got to draw the line somewhere |
| 23:16 | <Lachy> | let's make it the number of plank intervals since the big bang in a standardised hypothetical reference frame |
| 23:17 | Lachy | chooses to ignore the fact that our current estimate for the age of the earth has a 0.4 billion year margin of error. |
| 23:17 | <Lachy> | s/earth/univers/ |
| 23:17 | <Lachy> | *universe |
| 23:18 | <Philip`> | Wikipedia says it's more like +/- 0.12 billion years, which isn't nearly so bad |
| 23:18 | <kig> | you say -1, i say 2^32 |
| 23:18 | <Lachy> | oh, last I heard, it was +/- 0.2 |
| 23:19 | <Philip`> | http://en.wikipedia.org/wiki/Age_of_the_universe - "Current theory and observations suggest that this is between 13.61 and 13.85 billion years.[1]" - it's got a citation so it must be true |
| 23:20 | <Lachy> | did you actually follow the citation? |
| 23:20 | <Philip`> | Of course not |
| 23:20 | <kig> | i.. probably should've written a test generator rather than more tests |
| 23:21 | <Philip`> | kig: But if you wrote a test generator, you'd have to write tests for the test generator to make sure it doesn't have bugs |
| 23:21 | <Lachy> | the cited PDF has a table that lists the age of the universe as "013.72 ± 0.12 Gyr " in the column entitled "WMAP+BAO+SN" |
| 23:23 | <jcranmer> | how about the frame of reference of the Scott-Amundsen Research Base? |
| 23:23 | <kig> | Philip`: actually, if you take a fault injector that tests your tests (if your tests fail to catch the fault, your tests have a bug) and an evolutionary test generator and let them duke it out |
| 23:23 | <Philip`> | That only differs from Wikipedia by ten million years, which is neither here nor there |
| 23:24 | <Lachy> | sure, but if we're measuring in plank intervals, that's a huge margin of error |
| 23:24 | <jcranmer> | the Big Bang also happened on October 23, 4004 BC |
| 23:24 | <jcranmer> | :-) |
| 23:25 | <kig> | how near c do you have to be travelling for that to be true? |
| 23:25 | <Lachy> | jcranmer, did you just make up the October 23 date, or are there creationists actually claiming that's the specific date? |
| 23:25 | <Philip`> | I thought the Big Bang was the goal of Great A'Tuin in the distant future |
| 23:26 | <jcranmer> | Lachy: http://en.wikipedia.org/wiki/James_Ussher |
| 23:27 | <Lachy> | wow |
| 23:28 | <Philip`> | It's not like they had any better evidence to go by in those days |
| 23:28 | <rubys> | "Ussher was a gifted polyglot" :-) |
| 23:30 | <Philip`> | Polyglot sounds like a horrid disease |