00:02:40 And obviously we don't know about the rest of the system, what you do with the Unix-timestamp-corresponding-to-the-most-recent-Manila-midnight-that-has-already-happened. 00:02:50 :t (**) 00:02:51 forall a. (Floating a) => a -> a -> a 00:02:58 Hmm. Let's put this vaguely algebraically: Manila = UTC + 8 hours. Now, if you have the UTC time 12:00 and want that in Manila time, you add 8 hours. If you have the Manila time 12:00 and want that in UTC time, you subtract 8 hours (obviously). 00:03:17 fizzie: looks like Dagoth-Ur showed up in Arena too 00:03:31 Hrm. That's not quite helping... 00:03:35 Lessee. 00:04:29 pikhq_: The simplest prose-style explanation I can make for the "clamp to midnight, subtract eight" rule is: "clamp to midnight" represents UTC 00:00:00; after you subtract eight hours, it represents UTC 16:00:00; any UTC 16:00:00 time will be a Manila 00:00:00, because it's UTC+8. 00:04:42 fizzie: Right, that's a bit better. 00:04:52 myndzi: ^ 00:04:58 But I did try that out earlier and it didn't help, so it probably won't now, either. 00:05:41 Jesus are you still explaining counting to myndzi. 00:08:29 -!- oerjan has quit (Quit: Clearly you are doomed, good night.). 00:09:12 Anyway, if you look at Manila time of 04:00, the corresponding UTC time is 20:00 (subtract eight hours). When you clamp to midnight, you're subtracting 20 hours; so the UTC midnight will be Manila time 04:00-(20 hours) = 08:00. You will need to subtract 8 hours from that to get a midnight in Manila. (But it will be the midnight of the previous day, because you will be subtracting a total of 28 hours.) 00:10:21 For Manila 12:00, corresponding UTC is 04:00. Clamp to midnight means subtracting 4 hours. That UTC midnight is Manila time 08:00. Again, you will need to subtract 8 hours to get a midnight in Manila, and will end up subtracting a total of 12 hours, and you get the midnight of "today" in Manila. 00:12:26 In fact, any UTC midnight is going to always be 08:00AM in Manila, that's what UTC+8 means. If you want a midnight in Manila, you must subtract eight hours, or add 16. 00:13:36 myndzi: *drumroll* 00:13:43 (THIS IS EXCITING OKAY) 00:14:14 i'm writing. be patient 00:14:21 :'( 00:14:44 I'm not going to be awake to see how this ends, sadly; it's past 02am here. 00:14:54 there'll be a link for you tomorrow 00:14:55 :) 00:15:04 sorry for the frustration i've caused, thank you for your efforts 00:15:09 * elliott awaits eagerly. 00:16:52 (It is 02:15AM here in UTC+2. Currently it's 00:15AM in UTC. If you do a "clamp to UTC midnight" operation, you will subtract 15 minutes, so that time in my timezone will be 02:00AM. You'll need to subtract 2 more hours to get a local midnight. Substitute 8 for 2 for Manila. Sorry, couldn't resist.) 00:18:11 :D 00:19:02 (Current Unix timestamp is about 1322871375. 1322871375%86400 = 975, about 16 minutes. If you subtract that from current time, it's about 02am here. You will need to subtract further two hours from the Unix timestamp to get a Unix timestamp value that corresponds to our midnight. Sorry, couldn't resist that either.) 00:19:06 Okay, seriously. -> 00:22:32 (When the time was "today, 01:00am" here in Finland, it was 23:00 in UTC. If you clamped that timestamp to previous UTC midnight, you'd end up subtracting 23 hours, leading to "yesterday, 02:00am". Then you could subtract two more hours to get a local midnight, but it would be "yesterday, 00:00", a day earlier than you wanted. This might explain the issues you mentioned.) 00:22:38 Seriously for reals now. -> 00:22:39 -!- derdon has quit (Remote host closed the connection). 00:26:27 myndzi: I think fizzie is trolling you. 00:28:55 (If it was "today, 01:00am" here, and you wanted to round to local midnight, you could (I'm not sure I would): add two hours to the timestamp, so you'd have a Unix timestamp that'd translate to UTC 01:00am; a different instant in time, yet same in local time. Then clamp to UTC midnight, which would end up subtracting the "proper" one hour. Then you would reverse the initial "time zone conversion" by subtracting two hours, and end up with local "today, 00:00", U 00:28:55 TC. That sort of thing would work, though the idea of having Unix timestamps that represent time instants that have the "local time" value when converted-to-display-as-UTC is a bit iffy. But if you're doing something like that, it does work.) 00:29:06 No, maybe some of that stuff might actually help. 00:29:27 I mean, after talk of "timestamps in local time", it's not inconcievable it could be something like that. 00:30:28 fizzie: Hi. 00:32:21 (But I'm still pretty sure if you just get current time() value, round to previous multiple of 86400, then; (a) subtracting K hours will give a local midnight in the UTC+K timezone, but it could be the "wrong" midnight; and (b) adding K hours will not give a local midnight, assuming K is not 12; at least as long as the resulting value is treated as a real Unix timestamp and converted to local time properly.) 00:32:28 Okay, maybe I really should go. 00:32:53 `finger 00:32:55 /home/hackbot/hackbot.hg/multibot_cmds/lib/limits: line 5: exec: finger: not found 00:33:00 ... 00:33:39 What does "..." even mean? You say it so often. 00:34:09 -!- DCliche has joined. 00:34:57 ellipsis 00:35:21 That's not what it means, that's what it is. 00:35:33 In this case, 00:35:40 why doesn't finger exist? 00:35:44 * Phantom_Hoover → sleep 00:35:47 -!- Phantom_Hoover has quit (Quit: Leaving). 00:35:55 'Cause it's not installed? 00:35:58 $ finger 00:35:59 bash: finger: command not found 00:37:38 -!- Ngevd has quit (Ping timeout: 252 seconds). 00:37:40 (Also even after all this thinking, if I were making a "production" system, I'd seriously consider testing my thing at Manila local times of 04:00, 12:00 and 20:00, and checking that mycode(now()) approximately equals now()-4*3600, now()-12*3600 and now()-20*3600, respectively. Assuming now() returns current Unix timestamp, and mycode() is supposed to return a Unix timestamp corresponding to local midnight.) 00:37:41 -!- Klisz has quit (Ping timeout: 255 seconds). 00:37:48 `log \.\.\. 00:37:53 2010-10-22.txt:21:21:13: pikhq: Sure, neither of us can watch that, but... 00:38:15 fizzie: Having fun are we? 00:38:23 elliott: So much! 00:48:18 -!- GreaseMonkey has quit (Quit: The Other Game). 00:48:27 fizzie: I hope you're not still here. 00:50:32 Nooo... 00:51:52 -!- elliott has quit (Remote host closed the connection). 00:52:47 -!- elliott has joined. 00:53:09 fizzie: Keep not being here, then. 00:53:22 fizzie: (But I don't think myndzi is still here.) 00:54:11 -!- HalfTauRSquared has changed nick to PiRSquared17. 00:58:07 But I'm unsure why not: 1. Get current Unix timestamp. 2. Convert timestamp into a broken-down structure with 'year', 'month', 'day', 'hour', 'min', 'sec' members in timezone of interest; pretty much any language can do that. 3. Set hour = min = day = 0. 4. Convert structure to Unix timestamp. 5. Use result for DB query. 00:58:19 So simple there's no many places to go wrong; is easy to change the target timezone; and (major win?) works also for the large parts of the world that do the stupid DST thing, even during the changeover days. 00:58:33 Except I mean hour = min = sec = 0. 00:58:43 Seconds, days, who cares. 00:59:15 fizzie: I think it's because it looks like WHERE foo > ((bar - nonsense) + lol). 00:59:41 So it'd be either (a) actually learning SQL's trivial timezone facilities (which would take 5 minutes, as opposed to the 2 days invested so far; clearly unworkable, this is the Easiest Way) or (b) another round-trip. 00:59:51 I... guess it could be that. 01:00:05 fizzie: Well, *he* claims it's because he doesn't know much SQL. 01:00:50 -!- hagb4rd has quit (Quit: Nettalk6 - www.ntalk.de). 01:01:31 fizzie: How does one go from an SDL_Surface to its PixelFormat :P 01:01:33 If it's a programming language doing the thing, it doesn't need SQL. Though I suppose it could be that it's just a fixed query without parameters or something. 01:01:51 Uh, maybe you needed to lock it first? 01:01:56 fizzie: Well, what I meant is that foo and bar are both columns. 01:01:59 nonsense and lol being constants. 01:02:08 Also, eh? 01:02:55 The PixelFormat for the screen surface might be allowed to change. Maybe. Well, maybe not. 01:03:24 fizzie: Yes, but how do I get at it? 01:04:43 Uh, surface->format? 01:05:01 fizzie: Hmm. A thing that seems to be gleefully unexposed through the Haskell binding. I swear I've solved this problem before. 01:05:15 Ah, right, the binding. 01:05:25 I vaguely recall something about it too. 01:05:27 If only I remembered how. 01:05:31 Maybe I'll gerp. 01:05:32 grep. 01:05:41 Someone make a grep alterantive called gerp, that won't be confused at all. 01:05:44 So many tpyosk. 01:07:25 surfaceGetPixelFormat :: Surface -> PixelFormat 01:07:46 From the docs of Graphics.UI.SDL.Types. 01:08:29 Oh. 01:08:31 That might work. :p 01:08:42 fizzie: (A pure function...?) 01:09:08 Yeah, that's a bit funny. 01:09:32 surfaceGetPixelFormat surface 01:09:32 = unsafePerformIO $ 01:09:33 withForeignPtr surface $ \ptr -> 01:09:33 newForeignPtr_ =<< (\hsc_ptr -> peekByteOff hsc_ptr 4) ptr 01:09:39 Yeah, real pure. 01:10:04 fizzie: Well, there's nothing wrong with that for immutable fields. 01:10:12 You just said it could change is all. 01:10:22 I guess it doesn't. 01:10:36 After all, setvideomode returns a new screen surface. 01:10:46 Right. 01:11:05 Now to figure out why SDL-gfx circles are cyan despite being drawn with a white colour. 01:11:06 It is "read-only" in the SDL_Surface struct doc. 01:11:21 I have a feeling the answer may be very 90s. 01:12:22 ARGB <-> RGBA sort of mishaps can easily get cyan, but I guess there were mapping functions that took a PixelFormat. 01:12:54 white <- SDL.mapRGB (SDL.surfaceGetPixelFormat surf) 255 255 255 01:12:54 SDLP.box surf (SDL.Rect 10 10 10 10) white 01:13:01 is what it looks like now after changing circles to boxes :P 01:13:20 Which generates a single cyan pixel. *sign* :/ 01:13:34 Well, that certainly looks like it should be someone else's problem to make work right. 01:14:21 Maybe the lazy language made libSDL lazy too, and it couldn't be arsed to fill more bytes. 01:14:26 Heh. 01:14:31 Well, SDL-gfx is nothing "official", is it? 01:14:42 All these things are so dormant because nobody actually does software rendering in 2011. 01:14:53 And if they do they don't use wuss drawing libraries to do it. 01:16:34 fizzie: ARGB? 01:16:38 someone uses that? 01:16:39 why? 01:17:13 Why's mapRGB 'IO Pixel' anyway? I don't think PixelFormat structures ever change. (Though don't quote me on that.) ((Actually, come to think of it, the palettes probably are mutable.)) 01:17:23 Vorpal: I don't think it's any mor 01:17:31 fizzie: any mor? 01:17:31 e unnatural than RGBA. 01:17:33 ah 01:17:34 -!- zzo38 has joined. 01:17:49 fizzie: RBGA is just the normal way of doing it though afaik 01:17:55 elliott: I believe people mostly use sdl to get a opengl context these days, and sound of course 01:18:11 Also you get to write 0xaabbcc without having to add an explicit 00 if you don't-care about alpha. 01:18:20 heh 01:18:54 Vorpal: Sound? OpenAL these days, surely. 01:19:06 fizzie: nevertheless, ARGB is seldom seen when drawing stuff. Maybe in file formats? I don't know. 01:19:23 It's all /Open.L/ nowadays. 01:19:29 elliott: iirc openal is great for 3D sound, with positioning and such 01:19:43 elliott: but make it rather complicated to play, say, a stereo sound track 01:19:55 * elliott is planning to use OpenAL for AII, and that's 2D. 01:20:01 mhm 01:20:12 Vorpal: And of course in-memory it may easily end up being ABGR or BGRA if you read it byte-orientedly. 01:20:13 Mostly because some of that positioning stuff is relevant, if only to make further away sounds quieter. 01:20:25 fizzie: heh 01:20:46 fizzie: is that for little or big endian? 01:21:11 fizzie: but stuff like opengl does it as GLfloat[4] basically 01:22:10 The pixel buffers still have a format. But I suppose you normally aren't supposed to actually play with those bytes. 01:22:46 fizzie: you generally just send them along in buffer objects and such 01:23:06 Honestly, all I want to do is animate some circles going around each other. 01:23:10 Maybe I can use that gloss thing. 01:23:21 elliott: putpixel :P 01:23:27 Vorpal: From Haskell? 01:23:30 Rather slow. 01:23:31 elliott: ouch 01:23:44 Haskell's FFI is low-overhead, but not /that/ low-overhead. 01:23:51 elliott: could you do a real time software ray tracer in haskell? 01:24:03 You can't do that with C. 01:24:09 At least if realtime involves >10fps. 01:24:12 elliott: you can for some simple scenes 01:24:24 I have one that runs in 50 FPS for a plane, two balls and a cone here 01:24:29 I'm sure you could do it. Probably not on Unix. 01:24:29 on my core i8 01:24:30 err 01:24:31 i7* 01:24:36 it is using openmp 01:24:38 @ should be able to do ray-tracing just fine. 01:24:41 elliott: yes on unix 01:24:55 Vorpal: "Can Haskell do X in an environment practically designed to work against Haskell in areas such as X?" 01:24:56 elliott: it is part of a lab at university. We are running it on core i7s there 01:25:09 elliott: hm? 01:25:19 "Hm?"? 01:25:20 elliott: I'm just saying you can do it in C (actually C++ here...) 01:25:28 Sure, so? 01:25:29 elliott: you said you couldn't do it with C 01:25:57 Well, I thought you meant more complex scenes than that. 01:26:01 ah 01:26:34 Congrats, you named one of the few areas where the performance of tight, math-heavy loops that fit in cache is still relevant! 01:26:43 pikhq_: quite :P 01:26:50 * elliott thinks @ will raytrace just fine. 01:26:54 elliott: but you can to some degree do it on more complex scenes, you just need like way more CPUs :P 01:26:55 I've again forgotten what "Ncon" meant in the "caveats" field of glxinfo. I guess non-conformant, but that's not saying much either. 01:27:02 Pure mathematical code is pretty easy to eliminate all the overhead from. 01:27:06 Which, for perverse reasons, is what most people think of as more general "performance". 01:27:17 pikhq_: indeed not the case. 01:27:18 Just get things unboxed and the loop into an iteration and you're done. 01:27:32 pikhq_: it is however an area I'm greatly interested in. 01:28:22 elliott: I'd imagine worst-case scenario you'd have a @lang-subset->verified-safe-machine-code compiler and a way to execute verified-safe machine code. 01:28:29 @ might lose where you have a tight loop that involves a lot of operations on things larger than machine words and no allocation. 01:28:39 pikhq_: ray tracing is interesting. Especially real time ray tracing. Since there is no way we are going to get real time photon mapping (or even further away I believe: real time MLT) 01:28:39 There might be some overhead imposed there. 01:28:44 Or even make that assembly instead of @ lang. 01:28:58 pikhq_: Weelll, there's @ll. 01:29:03 But that's not really for human consumption. 01:29:13 Nor is assembly. :) 01:29:25 (@ll being an imperative, safe-by-construction language that shares @lang's type system.) 01:29:29 It's only human-used for perverse edge cases, or for perverse people. 01:29:35 (Kind of like LLVM IR, but with things like allocation built in to the language.) 01:29:41 pikhq_: boot loaders 01:29:46 pikhq_: demo scene 01:29:49 (@lang of course compiles down to @ll.) 01:29:52 Vorpal: Perverse edge case, perverse people. 01:29:53 pikhq_: I guess those count as perverse? 01:29:53 Vorpal: "perverse edge cases", "perverse people" 01:29:56 right 01:30:05 pikhq_: compiler writers? 01:30:11 for the generating bit 01:30:20 They're not actually human-writing assembly. 01:30:25 hm true 01:30:26 They're human-writing assembly generation. 01:30:31 Oh, @ will also lose where you have a tight loop that does allocation, and can deal with a slow allocation, but /cannot/ deal with a GC pause. 01:30:32 yeah 01:30:57 More commonly: @ will lose if you need a loop to not allocate but you can't get the @lang compiler to not allocate there. 01:31:16 Although since I can have pluggable GCs, you could run a low-throughput concurrent collector in those situations for that pool. 01:31:19 Dunno. 01:31:22 elliott: how well will @ keep up with hard realtime requirements? I know there aren't a lot of them on PCs. But one case comes to mind if you are interested. 01:31:29 Vorpal: Go on,. 01:31:33 s/,// 01:32:07 elliott: accelerometer in laptop. You want to send the "get the fucking head off the disk RIGHT NOW" command with hard realtime constraints when it happens. 01:32:17 Er, I think that's done in hardware. 01:32:23 elliott: not on thinkpads at least 01:32:30 You should get a refund. 01:32:33 elliott: you need a polling daemon running on it 01:32:35 But anyway, does that correspond to an interrupt on the host computer? 01:32:36 which sucks yes 01:32:39 What, polling? 01:32:42 elliott: yes 01:32:51 elliott: it is terrible 01:32:55 I don't *want* @ to be good at this. Your HD deserves to die if it's protected by such an infernal contraption. 01:33:11 If it caused a host interrupt instead, then I think @ would be able to handle it. 01:33:22 I mean, if you're under heavy load it might not work out. 01:33:24 Vorpal: Um, that's not going to be any worse on @ than on any other OS. 01:33:33 pikhq_: vxworks :P 01:33:34 But yeah, if you have a userspace polling daemon and that works, then @ will handle it. 01:33:38 But I'm shocked that it works. 01:33:49 If it needs to poll, pretty much any kernel is only going to poll when you jump back into kernel space. 01:33:51 elliott: I can't say I have tested it 01:34:03 Vorpal: Lend Sgeo your laptop and you'll find out. 01:34:08 elliott: aiee! 01:34:16 And probably not even that often; I'd be willing to bet it simply sets up a timer for the checking. 01:34:32 Which shouldn't be anything impossible for @. 01:34:35 Vorpal: Anyway, @ is designed for SSDs :) 01:34:37 elliott: anyway yes it seems like a terrible design due to not offering any protection during booting 01:34:40 and so on 01:34:49 Specifically, 1-2 Tio+ SSDs. 01:35:04 elliott: those are fucking expensive 01:35:11 Pretty much all you need is for @ to make reasonable guarantees on interrupts being handled (including timer interrupts) 01:35:12 Vorpal: They are now. 01:35:14 Vorpal: Presently. 01:35:18 good point 01:35:26 Vorpal: @ is designed for where computers will be, not where computers are and have been. 01:35:26 They probably won't be when I'm in my 20s. 01:35:40 by the time @ is done SSDs will be a thing of the past :P 01:35:47 pikhq_: Can I hire you to write my marketing copy? 01:35:54 elliott: Plausibly. :) 01:36:09 It'll be like those computer ads from the 60s. 01:36:19 By the time @ is done we've all been fused into the Core Mind, I'd say. 01:36:23 @. The revolutionary new system from @ Systems, Incorporated. 01:36:24 Plugin `compose' failed with: Unknown command: "The" 01:36:27 fizzie: At which point, no worries. 01:36:33 Vorpal: @ is designed for where computers will be, not where computers are and have been. <-- you mean DRM-filled pieces of crap designed to run C and .NET code? 01:36:44 Vorpal: That's where computers are, yes. 01:36:48 The *only* computer operations system powering the new Microsoft Singularity(tm) software. 01:36:53 pikhq_: and where they are going. 01:36:59 Vorpal: Not really. 01:37:07 Get it now before Omega gets it for you.(tm) 01:37:07 pikhq_: oh? I'm not sure we will get less DRM 01:37:10 Trusted @-puting Initiative. 01:37:24 Vorpal: I give it 10 years tops for the media companies to collapse entirely. 01:37:30 pikhq_: heh 01:37:32 Making DRM pointless. 01:37:35 Vorpal: I don't think mandatory hardware DRM will catch on 01:37:35 (well, more so) 01:37:39 pikhq_: what about DRM for games? 01:37:47 "media companies" 01:37:51 elliott: I *hope* it won't 01:37:54 Vorpal: So it's not something "computers" will suffer by the @-relevant definition 01:38:04 Though the game industry is probably *less* doomed than others. 01:38:13 pikhq_: but where will we be then? I don't think there is enough people to support open source for niche applications 01:38:31 pikhq_: DRM for autodesk? 01:38:33 stuff like that 01:38:33 Media =/= programming. 01:38:43 indeed 01:38:44 Although I don't know what pikhq_ intended by "media" exactly. 01:38:52 but those companies want DRM too 01:38:59 elliott: Mostly TV, music, movies. 01:39:19 * elliott thinks if Netflix's boost for original content gets off the ground, then it'll surviev. 01:39:20 *survive. 01:39:28 pikhq_: I can see more than just media wanting DRM: games, specialised applications 01:39:28 And I would consider Netflix a TV company. 01:39:47 Vorpal: I think specialised applications need DRM less than mass-market stuff. 01:39:52 elliott: hm 01:39:55 Because the people who want it can afford it, and nobody else wants it. 01:40:01 hah 01:40:04 And ofc the people who want it need support. 01:40:06 Because it's specialised. 01:40:15 And so the internet won't help for support. 01:40:28 elliott: mathematica then? It isn't exactly mass-market. But it is popular enough to find well seeded over torrents 01:40:53 maybe not the linux version, but certainly the windows version 01:41:06 What Wolfram wants has very little connection to what is reasonable or what anyone else wants 01:41:27 elliott: true. But other applications in the same general category. Mathlab perhaps. 01:41:44 Also, DRM is a quixotic effort anyways. 01:41:47 Vorpal: *Matlab 01:41:51 right 01:41:51 http://en.wikipedia.org/wiki/MATHLAB 01:41:52 Why even consider it? 01:41:53 I believe I can get AutoCAD from university btw 01:41:56 ok you guys. 01:41:57 https://docs.google.com/a/searchfanatics.com/spreadsheet/ccc?key=0Aqlaw_Uc29ZrdGRuMDVoQzcwR1VHQm1VV3AxZXZRX2c&hl=en_US#gid=0 01:41:59 MATHLAB is an on-line system providing machine aid for the mechanical symbolic processes encountered in analysis. It is capable of performing, automatically and symbolically, such common procedures as simplification, substitution, differentiation, polynomial factorization, indefinite integration, direct and inverse Laplace transforms, the solution of linear differential equations with constant coefficients, the solution of simultaneous linear equa 01:41:59 tions, and the inversion of matrices. It also supplies fairly elaborate bookkeeping facilities appropriate to its on-line operation. 01:42:04 have at it 01:42:13 myndzi: Did you read fizzie's last words? 01:42:22 nope, i've been writing all this time 01:42:27 which last words where 01:42:44 00:16:52: (It is 02:15AM here in UTC+2. Currently it's 00:15AM in UTC. If you do a "clamp to UTC midnight" operation, you will subtract 15 minutes, so that time in my timezone will be 02:00AM. You'll need to subtract 2 more hours to get a local midnight. Substitute 8 for 2 for Manila. Sorry, couldn't resist.) 01:42:44 00:18:11: :D 01:42:44 00:19:02: (Current Unix timestamp is about 1322871375. 1322871375%86400 = 975, about 16 minutes. If you subtract that from current time, it's about 02am here. You will need to subtract further two hours from the Unix timestamp to get a Unix timestamp value that corresponds to our midnight. Sorry, couldn't resist that either.) 01:42:47 00:19:06: Okay, seriously. -> 01:42:49 00:22:32: (When the time was "today, 01:00am" here in Finland, it was 23:00 in UTC. If you clamped that timestamp to previous UTC midnight, you'd end up subtracting 23 hours, leading to "yesterday, 02:00am". Then you could subtract two more hours to get a local midnight, but it would be "yesterday, 00:00", a day earlier than you wanted. This might explain the issues you mentioned.) 01:42:54 00:22:38: Seriously for reals now. -> 01:42:56 00:22:39: -!- derdon has quit (Remote host closed the connection). 01:42:58 00:26:27: myndzi: I think fizzie is trolling you. 01:43:00 00:28:55: (If it was "today, 01:00am" here, and you wanted to round to local midnight, you could (I'm not sure I would): add two hours to the timestamp, so you'd have a Unix timestamp that'd translate to UTC 01:00am; a different instant in time, yet same in local time. Then clamp to UTC midnight, which would end up subtracting the "proper" one hour. Then you would reverse the initial "time zone conversion" by subtracting two hours, and en 01:43:05 d up with local "today, 00:00", U 01:43:06 elliott: "AutoCAD 2012 was released on 2011, March 22" <-- wut. 01:43:07 00:28:55: TC. That sort of thing would work, though the idea of having Unix timestamps that represent time instants that have the "local time" value when converted-to-display-as-UTC is a bit iffy. But if you're doing something like that, it does work.) 01:43:11 00:29:06: No, maybe some of that stuff might actually help. 01:43:13 00:29:27: I mean, after talk of "timestamps in local time", it's not inconcievable it could be something like that. 01:43:16 00:30:28: fizzie: Hi. 01:43:18 00:32:21: (But I'm still pretty sure if you just get current time() value, round to previous multiple of 86400, then; (a) subtracting K hours will give a local midnight in the UTC+K timezone, but it could be the "wrong" midnight; and (b) adding K hours will not give a local midnight, assuming K is not 12; at least as long as the resulting value is treated as a real Unix timestamp and converted to local time properly.) 01:43:23 00:32:28: Okay, maybe I really should go. 01:43:25 [...] 01:43:26 a search term would have sufficed 01:43:27 :) 01:43:27 00:37:40: (Also even after all this thinking, if I were making a "production" system, I'd seriously consider testing my thing at Manila local times of 04:00, 12:00 and 20:00, and checking that mycode(now()) approximately equals now()-4*3600, now()-12*3600 and now()-20*3600, respectively. Assuming now() returns current Unix timestamp, and mycode() is supposed to return a Unix timestamp corresponding to local midnight.) 01:43:55 @tell fizzie myndzi's reply: https://docs.google.com/spreadsheet/ccc?key=0Aqlaw_Uc29ZrdGRuMDVoQzcwR1VHQm1VV3AxZXZRX2c&hl=en_US#gid=0 01:43:55 Consider it noted. 01:43:57 Why would such a thing require the co-operation of the OS at all? 01:43:59 it doesn't look like he got it anyway 01:44:00 That sounds stupid to me 01:44:16 and i don't think he was trolling me because everyone here thought i was crazy ;) 01:44:25 i thought i was crazy too until i sat down and thought about it 01:44:35 Sgeo: Such a what? 01:44:46 please do tell me if the spreadsheet makes it clear for you...? 01:45:04 myndzi: I only glanced at it. I'd rather leave it up to fizzie, so I guess we'll see tomorrow. 01:45:04 myndzi: no: "Firefox has detected that the server is redirecting the request for this address in a way that will never complete." 01:45:09 elliott, telling the HD head to get off of the disk in the event of significant motion 01:45:10 myndzi: broken for me 01:45:15 wtf 01:45:18 it's just a google docs link 01:45:19 Sgeo: Bitter, are we? 01:45:27 myndzi: *shrug* 01:45:29 myndzi: So, basically, you were discussing a *completely different thing* than we thought you were. 01:45:32 not going to spend time debugging 01:45:54 so, basically, you have no reading comprehension at all, as it was stated multiple times and clearly 01:45:56 -!- TeruFSX_ has quit (Read error: Connection reset by peer). 01:45:56 :P 01:45:57 elliott, I'm responding to something Vorpal said I thin 01:45:58 thinkl 01:46:04 Sgeo: what? 01:46:05 Sgeo: It was a joke. 01:46:15 Of course to go from 00:00:00 UTC+8 -> x UTC+0, you add 8 hours, thus getting 08:00:00 UTC+0. 01:46:18 Er, I think that's done in hardware. 01:46:18 elliott: not on thinkpads at least 01:46:20 Sgeo: because bad architecture 01:46:23 Oh, didn't see that 01:46:34 Sgeo: polling even 01:46:42 Erm, wait. Bleh. 01:46:44 No. 01:46:47 No you don't. 01:47:05 To go from x UTC+0 -> UTC+8 you add 8. To do the inverse you subtract. 01:47:12 so, basically, you have no reading comprehension at all, as it was stated multiple times and clearly <-- you just failed horribly at expressing yourself then 01:47:31 -!- TeruFSX has joined. 01:47:48 * elliott still thinks myndzi is wrong, but also thinks that multiple people arguing with myndzi is much less productive than the best person here arguing with myndzi alone. 01:47:49 * myndzi still thinks elliott is wrong, but also thinks that multiple people arguing with elliott is much less productive than the best person here arguing with elliott alone. 01:47:54 Rude. 01:48:20 I'm not sure about that for either of you. 01:48:25 Still talking about Unix timestamps and UTC? 01:48:36 PiRSquared17: not still. again. 01:48:42 Vorpal: ? 01:48:44 because myndzi bought it up 01:48:54 I'm not sure about that for either of you. 01:48:55 ? 01:49:01 elliott: indeed. 01:49:07 ? 01:49:12 I'm not going to specify further to avoid offending you both 01:50:13 Vorpal: (The best person is meant to be fizzie, and myndzi's response was scripted, if that's what you mean.) 01:50:38 not at all what I meant 01:50:39 but whatever 01:51:08 elliott: speaking of rendering, this is cool: https://en.wikipedia.org/wiki/Metropolis_light_transport 01:51:23 Vorpal: I know what you think you were getting at, but it doesn't really work as an insult at all. 01:51:38 elliott: who said insult? 01:51:41 Is there a name for the class of functions that can be expressed as an infinite term polynomial? 01:51:46 elliott: just forget it! 01:52:03 Sgeo: sure one such name is "functions that can be expressed as an infinite term polynomial" 01:52:47 i can't even find in the history the last time it was summed up, but somebody else restated it and i agreed 01:52:58