From apoleksicki at o2.pl Sat Aug 8 14:05:40 2009 From: apoleksicki at o2.pl (Antoni Piotr Oleksicki) Date: Sat, 8 Aug 2009 16:05:40 +0200 Subject: [local-time-devel] [PATCH] Make local-time operate correctly with timezones In-Reply-To: <650d085f0907310804gb1e49cfw613ffe81e3dd54e9@mail.gmail.com> References: <650d085f0907310804gb1e49cfw613ffe81e3dd54e9@mail.gmail.com> Message-ID: <292bc03e0908080705ta0b3cc7m60a4ed277c8e5c59@mail.gmail.com> Hi Max, 2009/7/31 Max Tilford : > One issue we ran into though, was the timestamp+ function, which fails when > it calls %offset-timestamp-part with the 'offset' keyword arg. I believe it > should be using the 'utc-offset' keyword, but I don't know enough about the > code to be sure. Could you confirm that? 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. Cheers, Antoni ======================================================= Sat Aug 8 15:51:48 CEST 2009 Maciej Katafiasz * Minor bugfix: :utc-offset instead of :offset New patches: [Minor bugfix: :utc-offset instead of :offset Maciej Katafiasz **20090808135148 Ignore-this: e20b7cff5ec220a83bd112265b06f99f ] hunk ./src/local-time.lisp 889 (defun timestamp+ (time amount unit &optional (timezone *default-timezone*) offset) (multiple-value-bind (nsec sec day) - (%offset-timestamp-part time unit amount :timezone timezone :offset offset) + (%offset-timestamp-part time unit amount :timezone timezone :utc-offset offset) (make-timestamp :nsec nsec :sec sec :day day))) Context: [Make timestamp manipulation functions take and respect timezone arguments. Maciej Katafiasz **20090727180103 Ignore-this: 79214728e4966f44d8d4587bd850c53b ] [Make WITH-DECODED-TIMESTAMP and related take timezone/offset arguments. Maciej Katafiasz **20090727175400 Ignore-this: 296084f8d9179fe257c69118b7123309 ] [Make ENCODE-TIMESTAMP accept timezones instead of fixed offsets. Maciej Katafiasz **20090727174013 Ignore-this: f6420e93d194396afb221821e1312652 ] [Use symbols instead of strings where possible. Maciej Katafiasz **20090724164920] [added a once failing test attila.lendvai at gmail.com**20090616143818 Ignore-this: 741ad01d47b47e15cb4877567d3ba9d9 ] [add a more useful error when find-timezone-by-location-name is used without reading in the timezone files attila.lendvai at gmail.com**20090616143733 Ignore-this: c982ca27ef16e7f865afece963b6c9be ] [fix (print (now)) when *timezone* is (find-timezone-by-location-name "UTC") attila.lendvai at gmail.com**20090616141707 Ignore-this: ac694826aa5e9719d41c51503e0a8785 ] [clean up gettimeofday stuff, follow sbcl's changes (but remain backward compatible) attila.lendvai at gmail.com**20090521170712 Ignore-this: 70b2754c0a254abb060dce0f15bb266 ] [remove superfluous eval-when around reread-timezone-repository attila.lendvai at gmail.com**20090513213236 Ignore-this: 337cf4b3d50d0714f2c4a4a3d84e356f ] [Local-time now passes all tests in CCL Daniel Lowe **20090417142203] [Changed lispworks/ccl kluge to another, better kluge Daniel Lowe **20090417142156] [In WITH-DECODED-TIMESTAMP, declare nsec type as ranged integer instead of FIXNUM Daniel Lowe **20090416204555] [clarification comment for the lispworks #_ situation attila.lendvai at gmail.com**20090324135651 Ignore-this: 1f97d85c23ecffd5806f7a3c137f8491 ] [Less intrusive version of the Lispworks patch for #_. Larry Clapp **20090324132813 Use an around method in ASDF's compile-op to set the readtable to ignore #_. This achieves the same end, but more elegantly, and doesn't pollute the regular readtable. ] [be more conservative when installing global reader macros as a lispwork workaround attila.lendvai at gmail.com**20090323142133 Ignore-this: dca64a6f7daa4d478beba41d1c102a16 ] [Work with Lispworks Larry Clapp **20090323132602 - Added a dummy reader macro for #_ so the #+ccl (... #_gettimeofday ... ) doesn't break the compile - Fix %unix-gettimeofday for Lisps other than CMU, SBCL, and CCL. ] [TAG local-time-1.0.1 Daniel Lowe **20090312154109] Patch bundle hash: e73b3171e05766c85871c682974425fdfbebeb0a -------------- next part -------------- A non-text attachment was scrubbed... Name: local-time.diff Type: text/x-patch Size: 3483 bytes Desc: not available URL: From apoleksicki at o2.pl Sat Aug 8 14:23:06 2009 From: apoleksicki at o2.pl (Antoni Piotr Oleksicki) Date: Sat, 8 Aug 2009 16:23:06 +0200 Subject: [local-time-devel] [PATCH] Make local-time operate correctly with timezones In-Reply-To: References: <292bc03e0907280539m1f0b8a6k7bc8ac99e16afbea@mail.gmail.com> <292bc03e0907280541o1e4aa818n1a04e82fba9c1ab0@mail.gmail.com> Message-ID: <292bc03e0908080723x76732754wca746fb06b4ef690@mail.gmail.com> Hi Attila, 2009/7/29 Attila Lendvai : > i've pushed a patch to the official repo that is non-controversial, > and pushed the rest to my local tree to start testing it locally. > my timezone related knowledge is not enough to review the patch, but > your mail is starred and i'll start using your changes. Great! We'll be awaiting your feedback. > after a really short glimpse i didn't like the introduction of the > constant +none-zone+. i'd much prefer seeing assert's all around where > both arguments are available, so that calling a public api function > with both a timezone and an offset results in an error signaled. > something along the line of this as the first line of each such > function: > (defmacro assert-proper-timezone-and-offset () > ?`(assert (or (not timezone-provided?) (not offset)))) The assert idea is good, but it is not why +none-zone+ is there. It is because previously some of the code was called without any timezone or offset arguments and simply assumed zero offset, which happens to be +UTC-zone+, which was then used. This was really rather messy and introducing +none-zone+ was the easiest way to signify an explicit offset without disturbing the rest of the code too much. We're not too happy about +none-zone+ either, but doing away with it would require a lot more changes, quite possibly API-breaking ones. > and for the internal functions using NIL's for the uninteresting position. Yep. There are more cleanup possibilities, amongst them reducing a lot of unnecessary duplication like what TIMESTAMP+ and TIMESTAMP- used to have. But we didn't want to go too far this route without first checking that it's going to have at least some chance of being accepted :). Cheers, Antoni & Maciej From attila.lendvai at gmail.com Sat Aug 8 17:02:28 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sat, 8 Aug 2009 19:02:28 +0200 Subject: [local-time-devel] [PATCH] Make local-time operate correctly with timezones In-Reply-To: <292bc03e0908080723x76732754wca746fb06b4ef690@mail.gmail.com> References: <292bc03e0907280539m1f0b8a6k7bc8ac99e16afbea@mail.gmail.com> <292bc03e0907280541o1e4aa818n1a04e82fba9c1ab0@mail.gmail.com> <292bc03e0908080723x76732754wca746fb06b4ef690@mail.gmail.com> Message-ID: > The assert idea is good, but it is not why +none-zone+ is there. It is > because previously some of the code was called without any timezone or > offset arguments and simply assumed zero offset, which happens to be > +UTC-zone+, which was then used. This was really rather messy and > introducing +none-zone+ was the easiest way to signify an explicit > offset without disturbing the rest of the code too much. We're not too > happy about +none-zone+ either, but doing away with it would require a > lot more changes, quite possibly API-breaking ones. couldn't (... &key (timezone nil timezone-provided?)) work, together with an assert and a type check? or am i way off? -- attila From mathrick at gmail.com Sat Aug 8 18:07:56 2009 From: mathrick at gmail.com (Maciej Katafiasz) Date: Sat, 8 Aug 2009 20:07:56 +0200 Subject: [local-time-devel] [PATCH] Make local-time operate correctly with timezones In-Reply-To: References: <292bc03e0907280539m1f0b8a6k7bc8ac99e16afbea@mail.gmail.com> <292bc03e0907280541o1e4aa818n1a04e82fba9c1ab0@mail.gmail.com> <292bc03e0908080723x76732754wca746fb06b4ef690@mail.gmail.com> Message-ID: <50b7e5180908081107v244d799aoe77d5bf7d88be3b4@mail.gmail.com> On Sat, Aug 8, 2009 at 7:02 PM, Attila Lendvai wrote: > couldn't (... &key (timezone nil timezone-provided?)) work, together > with an assert and a type check? > > or am i way off? Nope, it couldn't. The problem is not the arglist, but where it's called. Namely, DECODE-TIMESTAMP is called by WITH-DECODED-TIMESTAMP, which originally took no offset parameter. It in turn was called in several other places (coming from ADJUST-TIMESTAMP expansion) which provided no way to specify either the timezone or the offset and simply assumed that offset zero was meant, and for that used hardcoded +UTC-ZONE+. So in the middle of an API centered around explicit offsets, suddenly a timezone sprang up, and one you couldn't change at that. It's not pretty, but fixing this would need a lot more review of the code for this kind of inconsistencies, plus restructuring it in a way that'd have a lot more chances to break some clients. That's why we wanted to get the patch reviewed and opinionated before going down an uncertain route. It's quite probably possible to fix it up, but needs more time and work, so we'd like a green light for the general approach first. Cheers, Maciej From essdir at web.de Sun Aug 30 14:54:40 2009 From: essdir at web.de (Dirk Esser) Date: Sun, 30 Aug 2009 16:54:40 +0200 Subject: [local-time-devel] Bug: Obtaining the current time on CCL/Windows Message-ID: <4A9A92B0.7040906@web.de> Hello everybody, I just fetched the current version of the Local-Time library from the darcs repository, and stumbled across the following problem: when using CCL (1.3) on Windows, the external symbol "gettimeofday" is not defined, resulting in a failure of all functions calling "%get-current-time". For my purposes, I don't need sub-second resolution, so the fallback version is fine with me right now (so I tweaked the feature conditionals in "%get-current-time" in order to get it). Can anyone else confirm this behaviour of the library when using CCL on Windows? Regards Dirk Esser -- Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we.