From: SourceForge.net <no...@so...> - 2009-05-25 21:41:46
|
Bugs item #2796593, was opened at 2009-05-25 14:41 Message generated for change (Tracker Item Submitted) made by cybern8sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2796593&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 06. Time Measurement Group: obsolete: 8.4.7 Status: Open Resolution: None Priority: 5 Private: No Submitted By: robin (cybern8sf) Assigned to: Kevin B KENNY (kennykb) Summary: clock scan returns wrong result Initial Comment: this problem just occurred in my code running on a web server the other day. code has been working fine for years, all of a sudden this has started to happen. i think this bug must have been fixed; i am trying to find where/what level so i can have my hosting provider update the server software: [clock scan 05/24/09] = 1243137600 [clock format 1243137600 -format %m/%d/%y] = 05/23/09 [clock format 1243137600 -format %c] = Sat May 23 23:59:37 2009 TCL patchlevel = 8.4.7 Linux servername 2.6.12-1.1381_FC3 #1 Fri Oct 21 03:46:55 EDT 2005 i686 i686 i386 GNU/Linux a test run on my home linux box works correctly: $ tclsh % puts stdout [info patchlevel] 8.4.12 % puts stdout [clock scan 05/24/09] 1243148400 % puts stdout [clock format 1243148400 -format %m/%d/%y] 05/24/09 % ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2796593&group_id=10894 |
From: SourceForge.net <no...@so...> - 2009-05-26 00:32:57
|
Bugs item #2796593, was opened at 2009-05-25 14:41 Message generated for change (Comment added) made by cybern8sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2796593&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 06. Time Measurement Group: obsolete: 8.4.7 Status: Open Resolution: None Priority: 5 Private: No Submitted By: robin (cybern8sf) Assigned to: Kevin B KENNY (kennykb) Summary: clock scan returns wrong result Initial Comment: this problem just occurred in my code running on a web server the other day. code has been working fine for years, all of a sudden this has started to happen. i think this bug must have been fixed; i am trying to find where/what level so i can have my hosting provider update the server software: [clock scan 05/24/09] = 1243137600 [clock format 1243137600 -format %m/%d/%y] = 05/23/09 [clock format 1243137600 -format %c] = Sat May 23 23:59:37 2009 TCL patchlevel = 8.4.7 Linux servername 2.6.12-1.1381_FC3 #1 Fri Oct 21 03:46:55 EDT 2005 i686 i686 i386 GNU/Linux a test run on my home linux box works correctly: $ tclsh % puts stdout [info patchlevel] 8.4.12 % puts stdout [clock scan 05/24/09] 1243148400 % puts stdout [clock format 1243148400 -format %m/%d/%y] 05/24/09 % ---------------------------------------------------------------------- >Comment By: robin (cybern8sf) Date: 2009-05-25 17:32 Message: i do realize that it could be that this is not a problem with TCL at all, unless TCL was recently updated to the 8.4.7 version which introduced this problem. i suppose it could also be a bug in other system-level time related software or settings that affects how TCL is getting or manipulating time data. the fact that this was working fine only a week ago and the problem turned up somewhere after that time is suspicious. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2796593&group_id=10894 |
From: SourceForge.net <no...@so...> - 2009-05-26 01:40:23
|
Bugs item #2796593, was opened at 2009-05-25 17:41 Message generated for change (Settings changed) made by kennykb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2796593&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 06. Time Measurement Group: obsolete: 8.4.7 >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: robin (cybern8sf) Assigned to: Kevin B KENNY (kennykb) Summary: clock scan returns wrong result Initial Comment: this problem just occurred in my code running on a web server the other day. code has been working fine for years, all of a sudden this has started to happen. i think this bug must have been fixed; i am trying to find where/what level so i can have my hosting provider update the server software: [clock scan 05/24/09] = 1243137600 [clock format 1243137600 -format %m/%d/%y] = 05/23/09 [clock format 1243137600 -format %c] = Sat May 23 23:59:37 2009 TCL patchlevel = 8.4.7 Linux servername 2.6.12-1.1381_FC3 #1 Fri Oct 21 03:46:55 EDT 2005 i686 i686 i386 GNU/Linux a test run on my home linux box works correctly: $ tclsh % puts stdout [info patchlevel] 8.4.12 % puts stdout [clock scan 05/24/09] 1243148400 % puts stdout [clock format 1243148400 -format %m/%d/%y] 05/24/09 % ---------------------------------------------------------------------- >Comment By: Kevin B KENNY (kennykb) Date: 2009-05-25 21:40 Message: The symptoms look as if someone configured /etc/localtime to point to a time zone in /usr/share/zoneinfo/right. This will cause the system library to return a count of seconds from the Epoch that includes all the leap seconds that have been added to the clock since then - making it 34 seconds (your system shows 33, so it probably missed the last one) different from UTC. Some timekeeping folk think that tracking the leap seconds is ideal behaviour, but it is NOT what Posix specifies, which is why the 'right' time zones aren't enabled by default. Tcl depends on Posix behaviour; its model of leap seconds is to accept the jump and smooth over it. http://www.cl.cam.ac.uk/~mgk25/uts.txt gives the basic idea. Ignoring leap seconds has compelling advantages for calculation, and very few disadvantages in day-to-day usage. Unless you can get your system clock back to Posix compliance, I'm afraid that the localtime conversion is likely to continue to be 33 (34?) seconds off. ---------------------------------------------------------------------- Comment By: robin (cybern8sf) Date: 2009-05-25 20:32 Message: i do realize that it could be that this is not a problem with TCL at all, unless TCL was recently updated to the 8.4.7 version which introduced this problem. i suppose it could also be a bug in other system-level time related software or settings that affects how TCL is getting or manipulating time data. the fact that this was working fine only a week ago and the problem turned up somewhere after that time is suspicious. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2796593&group_id=10894 |
From: SourceForge.net <no...@so...> - 2009-05-26 19:26:41
|
Bugs item #2796593, was opened at 2009-05-25 14:41 Message generated for change (Comment added) made by cybern8sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2796593&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 06. Time Measurement Group: obsolete: 8.4.7 >Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: robin (cybern8sf) Assigned to: Kevin B KENNY (kennykb) Summary: clock scan returns wrong result Initial Comment: this problem just occurred in my code running on a web server the other day. code has been working fine for years, all of a sudden this has started to happen. i think this bug must have been fixed; i am trying to find where/what level so i can have my hosting provider update the server software: [clock scan 05/24/09] = 1243137600 [clock format 1243137600 -format %m/%d/%y] = 05/23/09 [clock format 1243137600 -format %c] = Sat May 23 23:59:37 2009 TCL patchlevel = 8.4.7 Linux servername 2.6.12-1.1381_FC3 #1 Fri Oct 21 03:46:55 EDT 2005 i686 i686 i386 GNU/Linux a test run on my home linux box works correctly: $ tclsh % puts stdout [info patchlevel] 8.4.12 % puts stdout [clock scan 05/24/09] 1243148400 % puts stdout [clock format 1243148400 -format %m/%d/%y] 05/24/09 % ---------------------------------------------------------------------- >Comment By: robin (cybern8sf) Date: 2009-05-26 12:25 Message: thanks for the update/information. the /etc/localtime file on this system isn't linked to anything, and its size does not match anything in /usr/share/zoneinfo/right. so i am not sure if this is the root cause. if you have any other thoughts/ideas, i'd appreciate them. ---------------------------------------------------------------------- Comment By: Kevin B KENNY (kennykb) Date: 2009-05-25 18:40 Message: The symptoms look as if someone configured /etc/localtime to point to a time zone in /usr/share/zoneinfo/right. This will cause the system library to return a count of seconds from the Epoch that includes all the leap seconds that have been added to the clock since then - making it 34 seconds (your system shows 33, so it probably missed the last one) different from UTC. Some timekeeping folk think that tracking the leap seconds is ideal behaviour, but it is NOT what Posix specifies, which is why the 'right' time zones aren't enabled by default. Tcl depends on Posix behaviour; its model of leap seconds is to accept the jump and smooth over it. http://www.cl.cam.ac.uk/~mgk25/uts.txt gives the basic idea. Ignoring leap seconds has compelling advantages for calculation, and very few disadvantages in day-to-day usage. Unless you can get your system clock back to Posix compliance, I'm afraid that the localtime conversion is likely to continue to be 33 (34?) seconds off. ---------------------------------------------------------------------- Comment By: robin (cybern8sf) Date: 2009-05-25 17:32 Message: i do realize that it could be that this is not a problem with TCL at all, unless TCL was recently updated to the 8.4.7 version which introduced this problem. i suppose it could also be a bug in other system-level time related software or settings that affects how TCL is getting or manipulating time data. the fact that this was working fine only a week ago and the problem turned up somewhere after that time is suspicious. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2796593&group_id=10894 |
From: SourceForge.net <no...@so...> - 2009-05-27 03:05:53
|
Bugs item #2796593, was opened at 2009-05-25 17:41 Message generated for change (Comment added) made by kennykb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2796593&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 06. Time Measurement Group: obsolete: 8.4.7 >Status: Pending Resolution: Invalid Priority: 5 Private: No Submitted By: robin (cybern8sf) Assigned to: Kevin B KENNY (kennykb) Summary: clock scan returns wrong result Initial Comment: this problem just occurred in my code running on a web server the other day. code has been working fine for years, all of a sudden this has started to happen. i think this bug must have been fixed; i am trying to find where/what level so i can have my hosting provider update the server software: [clock scan 05/24/09] = 1243137600 [clock format 1243137600 -format %m/%d/%y] = 05/23/09 [clock format 1243137600 -format %c] = Sat May 23 23:59:37 2009 TCL patchlevel = 8.4.7 Linux servername 2.6.12-1.1381_FC3 #1 Fri Oct 21 03:46:55 EDT 2005 i686 i686 i386 GNU/Linux a test run on my home linux box works correctly: $ tclsh % puts stdout [info patchlevel] 8.4.12 % puts stdout [clock scan 05/24/09] 1243148400 % puts stdout [clock format 1243148400 -format %m/%d/%y] 05/24/09 % ---------------------------------------------------------------------- >Comment By: Kevin B KENNY (kennykb) Date: 2009-05-26 23:05 Message: The localtime() library call on the web server is definitely returning a time that is 23 seconds off. The 23 seconds (which should be 24 as of 1 January of this year) is a dead giveaway that something is ticking TAI instead of UTC. http://support.ntp.org/bin/view/Support/TimeScales has some other ideas of what to check. The Posix standard is quite clear on the matter. time_t is supposed to ignore leap seconds. A number of Linux developers think they know better. Their 'improvements', generally speaking, cause only trouble. ---------------------------------------------------------------------- Comment By: robin (cybern8sf) Date: 2009-05-26 15:25 Message: thanks for the update/information. the /etc/localtime file on this system isn't linked to anything, and its size does not match anything in /usr/share/zoneinfo/right. so i am not sure if this is the root cause. if you have any other thoughts/ideas, i'd appreciate them. ---------------------------------------------------------------------- Comment By: Kevin B KENNY (kennykb) Date: 2009-05-25 21:40 Message: The symptoms look as if someone configured /etc/localtime to point to a time zone in /usr/share/zoneinfo/right. This will cause the system library to return a count of seconds from the Epoch that includes all the leap seconds that have been added to the clock since then - making it 34 seconds (your system shows 33, so it probably missed the last one) different from UTC. Some timekeeping folk think that tracking the leap seconds is ideal behaviour, but it is NOT what Posix specifies, which is why the 'right' time zones aren't enabled by default. Tcl depends on Posix behaviour; its model of leap seconds is to accept the jump and smooth over it. http://www.cl.cam.ac.uk/~mgk25/uts.txt gives the basic idea. Ignoring leap seconds has compelling advantages for calculation, and very few disadvantages in day-to-day usage. Unless you can get your system clock back to Posix compliance, I'm afraid that the localtime conversion is likely to continue to be 33 (34?) seconds off. ---------------------------------------------------------------------- Comment By: robin (cybern8sf) Date: 2009-05-25 20:32 Message: i do realize that it could be that this is not a problem with TCL at all, unless TCL was recently updated to the 8.4.7 version which introduced this problem. i suppose it could also be a bug in other system-level time related software or settings that affects how TCL is getting or manipulating time data. the fact that this was working fine only a week ago and the problem turned up somewhere after that time is suspicious. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2796593&group_id=10894 |
From: SourceForge.net <no...@so...> - 2009-05-27 03:18:30
|
Bugs item #2796593, was opened at 2009-05-25 17:41 Message generated for change (Comment added) made by kennykb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2796593&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 06. Time Measurement Group: obsolete: 8.4.7 >Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: robin (cybern8sf) Assigned to: Kevin B KENNY (kennykb) Summary: clock scan returns wrong result Initial Comment: this problem just occurred in my code running on a web server the other day. code has been working fine for years, all of a sudden this has started to happen. i think this bug must have been fixed; i am trying to find where/what level so i can have my hosting provider update the server software: [clock scan 05/24/09] = 1243137600 [clock format 1243137600 -format %m/%d/%y] = 05/23/09 [clock format 1243137600 -format %c] = Sat May 23 23:59:37 2009 TCL patchlevel = 8.4.7 Linux servername 2.6.12-1.1381_FC3 #1 Fri Oct 21 03:46:55 EDT 2005 i686 i686 i386 GNU/Linux a test run on my home linux box works correctly: $ tclsh % puts stdout [info patchlevel] 8.4.12 % puts stdout [clock scan 05/24/09] 1243148400 % puts stdout [clock format 1243148400 -format %m/%d/%y] 05/24/09 % ---------------------------------------------------------------------- >Comment By: Kevin B KENNY (kennykb) Date: 2009-05-26 23:18 Message: This may be fixable in the 8.5 and 8.6 series by having the configurator check for whether libc contains the 'time2posix' and 'posix2time' calls. The time will have to be swizzled when using C library calls to convert the time rather than doing it Tcl-fashion. This includes at least mktime, gmtime_r, localtime_r, and gettimeofday. It may also include zoneinfo parsing - more research is needed into how zoneinfo is set up in this case. Tcl is far from the only application that is broken by a non-Posix-compliant gettimeofday(). ---------------------------------------------------------------------- Comment By: Kevin B KENNY (kennykb) Date: 2009-05-26 23:05 Message: The localtime() library call on the web server is definitely returning a time that is 23 seconds off. The 23 seconds (which should be 24 as of 1 January of this year) is a dead giveaway that something is ticking TAI instead of UTC. http://support.ntp.org/bin/view/Support/TimeScales has some other ideas of what to check. The Posix standard is quite clear on the matter. time_t is supposed to ignore leap seconds. A number of Linux developers think they know better. Their 'improvements', generally speaking, cause only trouble. ---------------------------------------------------------------------- Comment By: robin (cybern8sf) Date: 2009-05-26 15:25 Message: thanks for the update/information. the /etc/localtime file on this system isn't linked to anything, and its size does not match anything in /usr/share/zoneinfo/right. so i am not sure if this is the root cause. if you have any other thoughts/ideas, i'd appreciate them. ---------------------------------------------------------------------- Comment By: Kevin B KENNY (kennykb) Date: 2009-05-25 21:40 Message: The symptoms look as if someone configured /etc/localtime to point to a time zone in /usr/share/zoneinfo/right. This will cause the system library to return a count of seconds from the Epoch that includes all the leap seconds that have been added to the clock since then - making it 34 seconds (your system shows 33, so it probably missed the last one) different from UTC. Some timekeeping folk think that tracking the leap seconds is ideal behaviour, but it is NOT what Posix specifies, which is why the 'right' time zones aren't enabled by default. Tcl depends on Posix behaviour; its model of leap seconds is to accept the jump and smooth over it. http://www.cl.cam.ac.uk/~mgk25/uts.txt gives the basic idea. Ignoring leap seconds has compelling advantages for calculation, and very few disadvantages in day-to-day usage. Unless you can get your system clock back to Posix compliance, I'm afraid that the localtime conversion is likely to continue to be 33 (34?) seconds off. ---------------------------------------------------------------------- Comment By: robin (cybern8sf) Date: 2009-05-25 20:32 Message: i do realize that it could be that this is not a problem with TCL at all, unless TCL was recently updated to the 8.4.7 version which introduced this problem. i suppose it could also be a bug in other system-level time related software or settings that affects how TCL is getting or manipulating time data. the fact that this was working fine only a week ago and the problem turned up somewhere after that time is suspicious. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2796593&group_id=10894 |