Re: [Chicken-users] utc-time-seconds and local-time-seconds rationale?
On 2014-05-07 13:12, Evan Hanson wrote: I agree, an annotation for deprecation warnings would be valuable. So this totally already exists, it just wasn't documented under (chicken types). In case anyone stumbles across this part of the archive: you can use the following type syntax to produce a warning, with advice to use bar instead: (: foo (deprecated bar)) Evan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] utc-time-seconds and local-time-seconds rationale?
On Tue, May 06, 2014 at 11:54:35PM +0200, Michele La Monaca wrote: On a side note, I've noticed these discrepancies on solaris, cygwin and mingw: (use posix) (print (time-string (seconds-local-time) %z) - (vector-ref (seconds-local-time) 9)) +0200 - -7200 (osx, chicken 4.8.0) +0200 - -7200 (linux, chicken 4.8.0.3) +0200 - -3600 (solaris, chicken 4.8.0.3) +0200 - -3600 (cygwin, chicken 4.8.0.3) +0200 - -3600 (mingw, chicken 4.8.0.4) In my opinion, large parts of the POSIX unit should die. They're broken, at the wrong level of abstraction and just generally unschemely. The reason these time things are breaking is because the libc time access is so varying across operating systems. But even though they're so broken, people use it and rely on it, so we can't simply put it out of its misery. Cheers, Peter -- http://www.more-magic.net ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] utc-time-seconds and local-time-seconds rationale?
Hi Peter, I agree with your assessment. It suggested an idea to me, which may or may not be that good: Use the type system to deprecate those parts know to be broken. Maybe it would even be a good idea to extend the type system for that purpose. By now all you can do is (: broken-thing deprecated) right? I'd actually love to still be able to keep the type checking working nevertheless. Maybe like so (: boken-thing correct-type-declaration deprecated) which should give the deprecation warning and still check the type. (I'm not yet completely sure that the suggested syntax can not be mistaken for something else.) However for the case at hand I'd even love a notation which allows to attach a custom message to the deprecated type. Possibly like this: (: boken-thing correct-type-declaration (deprecated result is wild guesswork, not calculated)) I hope this illustrates the idea... Best /Jörg Am 07.05.2014 09:31, schrieb Peter Bex: On Tue, May 06, 2014 at 11:54:35PM +0200, Michele La Monaca wrote: On a side note, I've noticed these discrepancies on solaris, cygwin and mingw: (use posix) (print (time-string (seconds-local-time) %z) - (vector-ref (seconds-local-time) 9)) +0200 - -7200 (osx, chicken 4.8.0) +0200 - -7200 (linux, chicken 4.8.0.3) +0200 - -3600 (solaris, chicken 4.8.0.3) +0200 - -3600 (cygwin, chicken 4.8.0.3) +0200 - -3600 (mingw, chicken 4.8.0.4) In my opinion, large parts of the POSIX unit should die. They're broken, at the wrong level of abstraction and just generally unschemely. The reason these time things are breaking is because the libc time access is so varying across operating systems. But even though they're so broken, people use it and rely on it, so we can't simply put it out of its misery. Cheers, Peter ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] utc-time-seconds and local-time-seconds rationale?
Peter Bex scripsit: In my opinion, large parts of the POSIX unit should die. They're broken, at the wrong level of abstraction and just generally unschemely. The reason these time things are breaking is because the libc time access is so varying across operating systems. In this case, it's a plain implementation failure: the simulation for tm_gmtoff on non-GNU/BSD systems is broken. Here's a patch: --- runtime.c.orig 2014-05-07 10:19:44.108430900 -0400 +++ runtime.c 2014-05-07 10:21:11.024402300 -0400 @@ -8180,9 +8180,9 @@ /* negative for west of UTC, but we want positive */ C_fix(-tmt-tm_gmtoff) #elif defined(__CYGWIN__) || defined(__MINGW32__) || defined(_WIN32) || defined(__WINNT__) - C_fix(mode == C_SCHEME_FALSE ? _timezone : 0) /* does not account for DST */ + C_fix(mode == C_SCHEME_FALSE ? _timezone - _daylight * 3600 : 0) #else - C_fix(mode == C_SCHEME_FALSE ? timezone : 0) /* does not account for DST */ + C_fix(mode == C_SCHEME_FALSE ? timezone - daylight * 3600 : 0) #endif ); C_kontinue(k, info); I don't know why whoever wrote this simply added a comment saying DST was not taken into account instead of taking it into account. Actually, avoiding tm_gmtoff altogether would be more portable. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org But that, he realized, was a foolish thought; as no one knew better than he that the Wall had no other side. --Arthur C. Clarke, The Wall of Darkness ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] utc-time-seconds and local-time-seconds rationale?
On 2014-05-07 12:01, Jörg F. Wittenberger wrote: However for the case at hand I'd even love a notation which allows to attach a custom message to the deprecated type. Possibly like this: I agree, an annotation for deprecation warnings would be valuable. Currently, it's totally on the user to go figure out why something's been deprecated and what to do about it; it would be nice to be able to include even something as simple as bar is deprecated, use baz instead in the warnings. Evan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] utc-time-seconds and local-time-seconds rationale?
Attached a fixed and tested (cygwin, solaris) patch. Regards, Michele On Wed, May 7, 2014 at 4:46 PM, John Cowan co...@mercury.ccil.org wrote: Peter Bex scripsit: In my opinion, large parts of the POSIX unit should die. They're broken, at the wrong level of abstraction and just generally unschemely. The reason these time things are breaking is because the libc time access is so varying across operating systems. In this case, it's a plain implementation failure: the simulation for tm_gmtoff on non-GNU/BSD systems is broken. Here's a patch: --- runtime.c.orig 2014-05-07 10:19:44.108430900 -0400 +++ runtime.c 2014-05-07 10:21:11.024402300 -0400 @@ -8180,9 +8180,9 @@ /* negative for west of UTC, but we want positive */ C_fix(-tmt-tm_gmtoff) #elif defined(__CYGWIN__) || defined(__MINGW32__) || defined(_WIN32) || defined(__WINNT__) - C_fix(mode == C_SCHEME_FALSE ? _timezone : 0) /* does not account for DST */ + C_fix(mode == C_SCHEME_FALSE ? _timezone - _daylight * 3600 : 0) #else - C_fix(mode == C_SCHEME_FALSE ? timezone : 0) /* does not account for DST */ + C_fix(mode == C_SCHEME_FALSE ? timezone - daylight * 3600 : 0) #endif ); C_kontinue(k, info); I don't know why whoever wrote this simply added a comment saying DST was not taken into account instead of taking it into account. Actually, avoiding tm_gmtoff altogether would be more portable. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org But that, he realized, was a foolish thought; as no one knew better than he that the Wall had no other side. --Arthur C. Clarke, The Wall of Darkness 0001-fix-timezone-offset-on-platforms-with-no-tm_gmtoff.patch Description: Binary data ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] utc-time-seconds and local-time-seconds rationale?
Michele La Monaca scripsit: Attached a fixed and tested (cygwin, solaris) patch. Thanks for testing. What was wrong with multiplying daylight by 3600 rather than introducing a conditional branch? -- John Cowan http://www.ccil.org/~cowanco...@ccil.org If a traveler were informed that such a man [as Lord John Russell] was leader of the House of Commons, he may well begin to comprehend how the Egyptians worshiped an insect. --Benjamin Disraeli ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] utc-time-seconds and local-time-seconds rationale?
daylight is non-zero if Daylight Savings Time is in effect. Non-zero doesn't mean 1. On Thu, May 8, 2014 at 12:52 AM, John Cowan co...@mercury.ccil.org wrote: Michele La Monaca scripsit: Attached a fixed and tested (cygwin, solaris) patch. Thanks for testing. What was wrong with multiplying daylight by 3600 rather than introducing a conditional branch? -- John Cowan http://www.ccil.org/~cowanco...@ccil.org If a traveler were informed that such a man [as Lord John Russell] was leader of the House of Commons, he may well begin to comprehend how the Egyptians worshiped an insect. --Benjamin Disraeli ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] utc-time-seconds and local-time-seconds rationale?
Hi, I am not an expert here, but I find these functions ill-defined. Both take as input a time-vector which already carries the timezone information (seconds west of UTC). So a time-seconds function just seems the right thing to me. Having to specify the local/utc prefix feels redundant, confusing and error-prone: (local-time-seconds (seconds-utc-time 0)) -3600.0 (utc-time-seconds (seconds-local-time 0)) 3600.0 Regards, Michele ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
