From antony.sequeira at gmail.com Thu Oct 1 19:11:24 2009 From: antony.sequeira at gmail.com (Antony Sequeira) Date: Thu, 1 Oct 2009 12:11:24 -0700 Subject: [local-time-devel] using get-universal-time insteasd of gettimeofday Message-ID: <6fb33c150910011211t17bfbdc9rf37b89897af75ed9@mail.gmail.com> Hi I tried to use local-time with CCL on windows vista 64 "Clozure Common Lisp Version 1.3-r11936 (WindowsX8664)! " And ran into ? (local-time:now) > Error: Can't resolve foreign symbol "gettimeofday" > While executing: CCL::RESOLVE-EEP, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > I posted on cll and was suggested to ask CCL mailing list But I thought I'd ask here first since I feel requiring CCL to provide gettimeofday on windows may be asking too much Basically I was wondering if it's easy to fix local-time to *fall back* to using the CL standard get-universal-time for this purpose I am also curious as to why gettimeofday is used instead of get-universal-time -Antony From dlowe at bitmuse.com Thu Oct 1 20:26:59 2009 From: dlowe at bitmuse.com (Daniel Lowe) Date: Thu, 01 Oct 2009 16:26:59 -0400 Subject: [local-time-devel] using get-universal-time insteasd of gettimeofday In-Reply-To: <6fb33c150910011211t17bfbdc9rf37b89897af75ed9@mail.gmail.com> References: <6fb33c150910011211t17bfbdc9rf37b89897af75ed9@mail.gmail.com> Message-ID: <4AC51093.4000400@bitmuse.com> Antony Sequeira wrote: > I am also curious as to why gettimeofday is used instead of get-universal-time get-universal-time doesn't have subsecond resolution. If you could provide us with your *FEATURES* and the appropriate windows call to use for subsecond resolution, please do. We can have that fixed for you quickly. There actually is a fallback to get-universal-time, but it's not being used on CCL for windows. Thanks, : Daniel : From antony.sequeira at gmail.com Fri Oct 2 07:44:21 2009 From: antony.sequeira at gmail.com (Antony Sequeira) Date: Fri, 2 Oct 2009 00:44:21 -0700 Subject: [local-time-devel] using get-universal-time insteasd of gettimeofday In-Reply-To: <4AC51093.4000400@bitmuse.com> References: <6fb33c150910011211t17bfbdc9rf37b89897af75ed9@mail.gmail.com> <4AC51093.4000400@bitmuse.com> Message-ID: <6fb33c150910020044nd6a5fd4i8bbcbcd0ec1dfd41@mail.gmail.com> On Thu, Oct 1, 2009 at 1:26 PM, Daniel Lowe wrote: > Antony Sequeira wrote: >> I am also curious as to why gettimeofday is used instead of get-universal-time > > get-universal-time doesn't have subsecond resolution. > > If you could provide us with your *FEATURES* and the appropriate windows call to > use for subsecond resolution, please do. ?We can have that fixed for you quickly. ? *features* (:5AM IT.BESE.ARNESI.MOPP::HAVE-MOP :ASDF :PRIMARY-CLASSES :COMMON-LISP :OPENMCL :CCL :CCL-1.2 :CCL-1.3 :CLOZURE :CLOZURE-COMMON-LISP :ANSI-CL :OPENMCL-UNICODE-STRINGS :OPENMCL-NATIVE-THREADS :OPENMCL-PARTIAL-MOP :MCL-COMMON-MOP-SUBSET :OPENMCL-MOP-2 :OPENMCL-PRIVATE-HASH-TABLES :X86-64 :X86_64 :X86-TARGET :X86-HOST :X8664-TARGET :X8664-HOST :WINDOWS-HOST :WINDOWS-TARGET :WIN64-TARGET :WIN64-HOST :64-BIT-TARGET :64-BIT-HOST :LITTLE-ENDIAN-TARGET :LITTLE-ENDIAN-HOST :WINDOWS) I haven't done windows stuff in a while Googling showed the following http://social.msdn.microsoft.com/forums/en/vcgeneral/thread/430449b3-f6dd-4e18-84de-eebd26a8d668/ http://www.gamedev.net/community/forums/topic.asp?topic_id=401254 I'd be more than happy just to get the fall back to get-universal-time Rest of this is just my opinions and I am very grateful that local-time is available, please keep that in mind when reading the comments below. I am curious why subsecond resolution is used in local-time. Why do you use subsecond resolution in a wall clock lib. Most uses (that I know of for such things) is to associate a wall time with some direct or indirect user action. It shouldn't matter when you debit an account what millisecond it was. If two users hit at the same time, you still can't use wall clock milliseonds to say who hit first, cause who gets serviced and how far that service for a user has progressed has little do with the exact millisecond those users imitated their actions at their end. Also in a server farm env expecting millisecond consistency in wall clocks is not possible. If you can't expect that within a farm, then there isn't much point in expecting it within a server from a business point of view Also the OS can be adjusting the clock continuously and also due to ntp. If you are measuring large intervals then it's ok to use wall clock , but then on large intervals milliseconds don't matter On small intervals, wall-clock is not the right thing to use due to the above reasons I am guessing the main issue/use of subsecond is with db timestamp columns. I haven't worked out that part :) > > There actually is a fallback to get-universal-time, but it's not being used on > CCL for windows. > > Thanks, > > : Daniel : > Thank You -Antony From attila.lendvai at gmail.com Fri Oct 2 08:19:55 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 2 Oct 2009 10:19:55 +0200 Subject: [local-time-devel] Bug: Obtaining the current time on CCL/Windows In-Reply-To: <4A9D4FE9.8030605@web.de> References: <4A9A92B0.7040906@web.de> <4A9D4FE9.8030605@web.de> Message-ID: > The patch is attached to this email. pushed, thanks! and sorry for the delay, -- attila From attila.lendvai at gmail.com Fri Oct 2 08:21:01 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 2 Oct 2009 10:21:01 +0200 Subject: [local-time-devel] using get-universal-time insteasd of gettimeofday In-Reply-To: <6fb33c150910020044nd6a5fd4i8bbcbcd0ec1dfd41@mail.gmail.com> References: <6fb33c150910011211t17bfbdc9rf37b89897af75ed9@mail.gmail.com> <4AC51093.4000400@bitmuse.com> <6fb33c150910020044nd6a5fd4i8bbcbcd0ec1dfd41@mail.gmail.com> Message-ID: there was a patch lingering on the list which fixed this already. i've pushed it. sorry for the delay, -- attila From attila.lendvai at gmail.com Fri Oct 2 08:06:54 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 2 Oct 2009 10:06:54 +0200 Subject: [local-time-devel] [PATCH] Make local-time operate correctly with timezones In-Reply-To: <292bc03e0908080705ta0b3cc7m60a4ed277c8e5c59@mail.gmail.com> References: <650d085f0907310804gb1e49cfw613ffe81e3dd54e9@mail.gmail.com> <292bc03e0908080705ta0b3cc7m60a4ed277c8e5c59@mail.gmail.com> Message-ID: > Thanks for the bug report, it was that. Sorry for the delay, but > things were a bit busy. Anyway, here's the patch, as promised in the > earlier mail that accidentally didn't go to the list. pushed, thanks! and sorry for the delay... -- attila From attila.lendvai at gmail.com Fri Oct 2 08:09:33 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 2 Oct 2009 10:09:33 +0200 Subject: [local-time-devel] [PATCH] Make local-time operate correctly with timezones In-Reply-To: <292bc03e0907271156j758640f9i840e660092df4a48@mail.gmail.com> References: <292bc03e0907271156j758640f9i840e660092df4a48@mail.gmail.com> Message-ID: > We have (together with Maciej Katafiasz) been working on making > local-time work correctly with regard to timezones. The changes are > quite extensive, but it seems to give correct results now in about > every operation we could think of. That includes overflowing into or > from DST. To achieve that we had to add timezone/offset arguments to > several functions. The biggest changes are in the ADJUST-TIMESTAMP > helper functions (%OFFSET-TIMESTAMP-PATY and %SET-TIMESTAMP-PART). > Additionally we corrected the rather schizophrenic nature of > WITH-DECODED-TIMESTAMP, which took timezone but not offset, unlike > everything else. > > The changes are API compatible, so there shouldn't be any breakage to > existing code. The semantics did change, but as far as we can tell the > old semantics were buggy, so it's unlikely that any client would want > them this way. Note that the changes include the patch from Thomas > Munro to ENCODE-TIMESTAMP, together with the DST ambiguity. That > ambiguity carries over to ADJUST-TIMESTAMP when used with symbolic > arguments (month and year) but not the precise ones i.e. nsec, sec, > day, hour, minute. If you don't like the ambiguity and have a good > idea how to solve it, we'll be glad to implement that. But personally > we think it's fine simply to document that explicitly. > > Below is a simple test suite that fails in the upstream version but > works fine with our changes. It's by no means exhaustive, but it does > touch most of the interesting cases. i've been using these patches for a while locally and recently pushed them to the official repo. i did not go through a deep code review, but this patch seems to be worth much more than letting it rest on a mailing list. if it breaks something then please speak up, or even better just send fixes! :) thanks, -- attila From antony.sequeira at gmail.com Fri Oct 2 10:25:44 2009 From: antony.sequeira at gmail.com (Antony Sequeira) Date: Fri, 2 Oct 2009 03:25:44 -0700 Subject: [local-time-devel] using get-universal-time insteasd of gettimeofday In-Reply-To: References: <6fb33c150910011211t17bfbdc9rf37b89897af75ed9@mail.gmail.com> <4AC51093.4000400@bitmuse.com> <6fb33c150910020044nd6a5fd4i8bbcbcd0ec1dfd41@mail.gmail.com> Message-ID: <6fb33c150910020325q4b994a8dgbac847a09a8ff0f7@mail.gmail.com> (local-time:now) works, thanks But (asdf:operate 'asdf:test-op :local-time) ..... ;Compiler warnings for "c:/git/thirdparty/local-time/src/local-time.lisp" : ; In (COMPILER-MACRO-FUNCTION TIMESTAMP<): Unused lexical variable TIME ; In (COMPILER-MACRO-FUNCTION TIMESTAMP<=): Unused lexical variable TIME ; In (COMPILER-MACRO-FUNCTION TIMESTAMP>): Unused lexical variable TIME ; In (COMPILER-MACRO-FUNCTION TIMESTAMP>=): Unused lexical variable TIME ; In (COMPILER-MACRO-FUNCTION TIMESTAMP=): Unused lexical variable TIME ; In (COMPILER-MACRO-FUNCTION TIMESTAMP/=): Unused lexical variable TIME ; Warning: COMPILE-FILE warned while performing # on #. ; While executing: #, in process listener(1). > Error: Undefined function REREAD-TIMEZONE-REPOSITORY called with arguments () . > While executing: #, in process listener(1). .... I ran this before and it used to compile and just fail a few tests On Fri, Oct 2, 2009 at 1:21 AM, Attila Lendvai wrote: > there was a patch lingering on the list which fixed this already. i've > pushed it. > > sorry for the delay, > > -- > ?attila > From daniel at whitehouse.id.au Thu Oct 22 14:41:44 2009 From: daniel at whitehouse.id.au (Daniel White) Date: Fri, 23 Oct 2009 01:41:44 +1100 Subject: [local-time-devel] [PATCH] Provide support for formatting days as an ordinal Message-ID: <20091023014144.0bba19ca@whitehouse.id.au> Basically allows :ordinal-day as a formatting parameter that generates output such as 1st, 23rd, and 30th. -------------- next part -------------- A non-text attachment was scrubbed... Name: ordinal-day.dpatch Type: text/x-darcs-patch Size: 6502 bytes Desc: not available URL: -------------- next part -------------- -- Daniel White From dlowe at bitmuse.com Thu Oct 22 15:56:09 2009 From: dlowe at bitmuse.com (Daniel Lowe) Date: Thu, 22 Oct 2009 11:56:09 -0400 Subject: [local-time-devel] [PATCH] Provide support for formatting days as an ordinal In-Reply-To: <20091023014144.0bba19ca@whitehouse.id.au> References: <20091023014144.0bba19ca@whitehouse.id.au> Message-ID: <4AE08099.4080005@bitmuse.com> Daniel White wrote: > Basically allows :ordinal-day as a formatting parameter that generates > output such as 1st, 23rd, and 30th. Looks great, Daniel. Committed to the main repository. : Daniel : From arbscht at gmail.com Thu Oct 29 03:02:34 2009 From: arbscht at gmail.com (Abhishek Reddy) Date: Thu, 29 Oct 2009 16:02:34 +1300 Subject: [local-time-devel] local-time in the Pacific Message-ID: <6da08ade0910282002j23bb10fak7fdba1f99bfafaf3@mail.gmail.com> Hi local-time still declaims that offsets must be in the range (integer -43199 43199) -- a maximum approaching +12 hours. This excludes NZST (UTC+12), NZDT (UTC+13) and other valid zones up to UTC+14. A range of (integer -43199 50400) would allow timestamps in all Pacific zones in zoneinfo to be used. This was reported some months ago, but it appears not to have had any response.[1] It looks like a bug to me; is there any chance this could be fixed? [1] http://common-lisp.net/pipermail/local-time-devel/2009-January/000132.html Thanks -- Abhishek Reddy http://abhishek.geek.nz -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.lendvai at gmail.com Thu Oct 29 12:24:31 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 29 Oct 2009 13:24:31 +0100 Subject: [local-time-devel] local-time in the Pacific In-Reply-To: <6da08ade0910282002j23bb10fak7fdba1f99bfafaf3@mail.gmail.com> References: <6da08ade0910282002j23bb10fak7fdba1f99bfafaf3@mail.gmail.com> Message-ID: > local-time still declaims that offsets must be in the range (integer -43199 > 43199) -- a maximum approaching +12 hours.? This excludes NZST (UTC+12), > NZDT (UTC+13) and other valid zones up to UTC+14.? A range of (integer > -43199 50400) would allow timestamps in all Pacific zones in zoneinfo to be > used. > > This was reported some months ago, but it appears not to have had any > response.[1]? It looks like a bug to me; is there any chance this could be > fixed? thanks, fix pushed! -- attila From arbscht at gmail.com Thu Oct 29 18:33:52 2009 From: arbscht at gmail.com (Abhishek Reddy) Date: Fri, 30 Oct 2009 07:33:52 +1300 Subject: [local-time-devel] Locating the zoneinfo repository Message-ID: <6da08ade0910291133k4f15fe70sac165c9b707dfba7@mail.gmail.com> Hi, As I understand it, local-time attempts to locate the zoneinfo/ directory in two places: relative to the ASDF package path, or at *load-pathname*. However, this seems like a fragile, even buggy, strategy for some use cases: * When LOAD-ing local-time (not via ASDF) while ASDF is incidentally loaded into the image, local-time will try to locate the ASDF package path anyway, ignoring *load-pathname*. The result may be NIL, yielding an error in constructing the pathname. * When LOAD-ing local-time (not via ASDF) while there is no ASDF in the image, *project-home-directory* will default to the directory of *load-pathname*, which in the current source tree layout is src/ -- whereas the repository is under src/../ -- eventually causing an error in TRUENAME. * In a saved image that includes local-time (via ASDF) and ASDF itself, the value of *project-home-directory* may be set at the time of saving.[1] If the image is deployed in a different environment, it may not find the repository, eventually causing an error in TRUENAME. * In a saved image that includes local-time but excludes ASDF, the package path cannot be found, and *load-pathname* may be NIL.[2] This yields an error in constructing the pathname, before the client has a chance to do anything about it. Is there a better way to use local-time in these cases, or is it worth modifying the way local-time locates the zoneinfo repository? For now, I have resorted to making the following changes to local-time: * Allow *project-home-directory* to be NIL, if the ASDF and LOAD-time paths cannot be used. It is assumed that the library client will take responsibility for updating the null parameter (and for distributing zoneinfo/ as an external asset). * Define a parameter in the local-time.system package that is bound when ASDF performs a load-op on local-time source files, and use its value in local-time if available. * When *load-pathname* is to be used, select its parent directory. The attached patch contains these changes (against a recent darcs rev.) as a proof of concept. It is only a working implementation, allowing saved images to use local-time, and loading it without ASDF. AFAIK, it does not introduce breaking changes. I would like to get general feedback/advice on the direction before going further. [1] for example in an executable generated by sb-ext:save-lisp-and-die in SBCL. [2] for example in a monolithic executable generated by asdf:make-build in ECL. Thanks -- Abhishek Reddy http://abhishek.geek.nz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: local-time-project-home.patch Type: text/x-diff Size: 2450 bytes Desc: not available URL: From attila.lendvai at gmail.com Fri Oct 30 09:57:55 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 30 Oct 2009 10:57:55 +0100 Subject: [local-time-devel] Locating the zoneinfo repository In-Reply-To: <6da08ade0910291133k4f15fe70sac165c9b707dfba7@mail.gmail.com> References: <6da08ade0910291133k4f15fe70sac165c9b707dfba7@mail.gmail.com> Message-ID: thanks for the patch and description! i did not apply the patch as-is though (e.g. defining methods on asdf classes), but i pushed something along the lines of your patch. > ? * When LOAD-ing local-time (not via ASDF) while ASDF is incidentally > loaded into the image, local-time will try to locate the ASDF package path > anyway, ignoring *load-pathname*.? The result may be NIL, yielding an error > in constructing the pathname. fixed > ? * When LOAD-ing local-time (not via ASDF) while there is no ASDF in the > image, *project-home-directory* will default to the directory of > *load-pathname*, which in the current source tree layout is src/ -- whereas > the repository is under src/../ -- eventually causing an error in TRUENAME. fixed > ? * In a saved image that includes local-time (via ASDF) and ASDF itself, > the value of *project-home-directory* may be set at the time of saving.[1] > If the image is deployed in a different environment, it may not find the > repository, eventually causing an error in TRUENAME. that's the usual issue which needs to be taken care of the one who saves the image. if static timezone files are ok, then read them before saving. if they are not, then no smartness is enough to handle the issue without the saver's help. i've added a key arg to reread-timezone-repository to help dealing with the issue (although it's still not exported for now). > ? * In a saved image that includes local-time but excludes ASDF, the package > path cannot be found, and *load-pathname* may be NIL.[2]? This yields an > error in constructing the pathname, before the client has a chance to do > anything about it. should be fixed please get the latest from darcs and report back with any issues that remain! thanks, -- attila From arbscht at gmail.com Fri Oct 30 21:22:15 2009 From: arbscht at gmail.com (Abhishek Reddy) Date: Sat, 31 Oct 2009 10:22:15 +1300 Subject: [local-time-devel] Locating the zoneinfo repository In-Reply-To: References: <6da08ade0910291133k4f15fe70sac165c9b707dfba7@mail.gmail.com> Message-ID: <6da08ade0910301422w425b23eoec0e8a46042e3309@mail.gmail.com> Hi, On Fri, Oct 30, 2009 at 10:57 PM, Attila Lendvai wrote: > > * When LOAD-ing local-time (not via ASDF) while ASDF is incidentally > > loaded into the image, local-time will try to locate the ASDF package > path > > anyway, ignoring *load-pathname*. The result may be NIL, yielding an > error > > in constructing the pathname. > > > > fixed > Works for me. > * When LOAD-ing local-time (not via ASDF) while there is no ASDF in the > > image, *project-home-directory* will default to the directory of > > *load-pathname*, which in the current source tree layout is src/ -- > whereas > > the repository is under src/../ -- eventually causing an error in > TRUENAME. > > > fixed > Works for me. > > * In a saved image that includes local-time (via ASDF) and ASDF > itself, > > the value of *project-home-directory* may be set at the time of > saving.[1] > > If the image is deployed in a different environment, it may not find the > > repository, eventually causing an error in TRUENAME. > > > that's the usual issue which needs to be taken care of the one who > saves the image. if static timezone files are ok, then read them > before saving. if they are not, then no smartness is enough to handle > the issue without the saver's help. > Okay, but maybe local-time can handle the case more consistently. See below about conditions. > * In a saved image that includes local-time but excludes ASDF, the > package > > path cannot be found, and *load-pathname* may be NIL.[2] This yields an > > error in constructing the pathname, before the client has a chance to do > > anything about it. > > > should be fixed > Still a problem in ECL since (or *compile-file-truename* *load-truename*) => NIL. Merging "../" fails before the client gets control. This works: diff -rN old-local-time/src/local-time.lisp new-local-time/src/local-time.lisp 201c201 < (try (merge-pathnames "../" path))) --- > (when path (try (merge-pathnames "../" path)))) Is the noisy warning necessary? In ECL, it writes to stderr just before the client code runs. In a saved executable, it is expected that the directory might not be found at boot, so the warning is not useful there. Muffling the warning from the client side could be unnecessarily complicated (I'm not sure if it is even possible), or might affect other unexpected warnings or stderr messages. In SBCL, the saved path is not checked at boot, and no warning is raised -- which is inconsistent with the behaviour in ECL. I would prefer instead a condition/error to be generated when an invalid project home directory is used, with a descriptive report. Signalling late in the program should make local-time's behaviour more consistent and predictable. (It would even help in the case of an interactive session -- suppose something in the filesystem changes after the parameter is initialized.) Attached is a patch demonstrating one kind of condition scheme. Is something like this viable? Thanks! -- Abhishek Reddy http://abhishek.geek.nz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: local-time-invalid-directory.patch Type: text/x-diff Size: 2664 bytes Desc: not available URL: From attila.lendvai at gmail.com Sat Oct 31 00:14:02 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sat, 31 Oct 2009 01:14:02 +0100 Subject: [local-time-devel] Locating the zoneinfo repository In-Reply-To: <6da08ade0910301422w425b23eoec0e8a46042e3309@mail.gmail.com> References: <6da08ade0910291133k4f15fe70sac165c9b707dfba7@mail.gmail.com> <6da08ade0910301422w425b23eoec0e8a46042e3309@mail.gmail.com> Message-ID: >> that's the usual issue which needs to be taken care of the one who >> saves the image. if static timezone files are ok, then read them >> before saving. if they are not, then no smartness is enough to handle >> the issue without the saver's help. > > Okay, but maybe local-time can handle the case more consistently.? See below > about conditions. ahh, i forgot to push a change that adds a key arg to the reread function. anyways, i've amended that patch and pushed another take on the issue. > Still a problem in ECL since (or *compile-file-truename* *load-truename*) => > NIL.? Merging "../" fails before the client gets control.? This works: > > diff -rN old-local-time/src/local-time.lisp > new-local-time/src/local-time.lisp > 201c201 > --- >>?????????? (when path (try (merge-pathnames "../" path)))) thanks, this is pushed too. > I would prefer instead a condition/error to be generated when an invalid > project home directory is used, with a descriptive report.? Signalling late > in the program should make local-time's behaviour more consistent and > predictable.? (It would even help in the case of an interactive session -- > suppose something in the filesystem changes after the parameter is > initialized.) i got rid of the warning and followed your basic idea, but that condition is too much, i just added an (error "foo) call. hope it'll resolve all the issues, -- attila From arbscht at gmail.com Sat Oct 31 00:34:36 2009 From: arbscht at gmail.com (Abhishek Reddy) Date: Sat, 31 Oct 2009 13:34:36 +1300 Subject: [local-time-devel] Locating the zoneinfo repository In-Reply-To: References: <6da08ade0910291133k4f15fe70sac165c9b707dfba7@mail.gmail.com> <6da08ade0910301422w425b23eoec0e8a46042e3309@mail.gmail.com> Message-ID: <6da08ade0910301734q48f8bc0dq336586f6f3498d16@mail.gmail.com> On Sat, Oct 31, 2009 at 1:14 PM, Attila Lendvai wrote: > > hope it'll resolve all the issues, > I think it does -- thanks! -- Abhishek Reddy http://abhishek.geek.nz -------------- next part -------------- An HTML attachment was scrubbed... URL: