Re: date anomalies when converting to seconds

On 5/25/06, Rob Cozens [EMAIL PROTECTED] wrote: so I had to learn to deal with dates spanning at least a century. I continue to prefer Julian notation personally. I downloaded Sarah's date time functions, and although they worked, I found that they were far to long and complex, that I

Re: date anomalies when converting to seconds

Hi Kay, Since it seems unlikely that I will get what I want, I am gradually starting to use my own numeric dateTime format and conversion routines: MMDD, HHMMSS or the 2 combined. As well as being totally numeric which is great for sorting, they have the advantage of being human-readable.

Re: date anomalies when converting to seconds

On 24 May 2006, at 06:58, Kay C Lan wrote: Of course you do need to be careful of the centuryCutoff property which is supposedly set to 35, and when I put the centuryCutoff I get 35 but: put 2006,05,23,12,12,12,999 into tMyDateTime add 11563 to item 3 of tMyDateTime convert tMyDateTime

Re: date anomalies when converting to seconds

On May 23, 2006, at 10:44 PM, Sarah Reichelt wrote: You're welcome. As everyone who reads these lists will know, I've done a lot of whinging about this problem. I would like a localSeconds that just got converted regardless of time zone, daylight savings or anything else, so that the same

Re: date anomalies when converting to seconds

Sarah- Tuesday, May 23, 2006, 9:44:06 PM, you wrote: You're welcome. As everyone who reads these lists will know, I've done a lot of whinging about this problem. I would like a localSeconds that just got converted regardless of time zone, daylight savings or anything else, so that the same

Re: date anomalies when converting to seconds

On May 24, 2006, at 8:29 AM, Dave Cragg wrote: The seconds value can't be used for dates and times beyond 3:14 am on January 18, 2038, which I guess translates into issues for the dateItems too. See here: http://home.netcom.com/~rogermw/Y2038.html Thank you! I have a vague memory of

Re: date anomalies when converting to seconds

On 5/24/06, Rob Cozens [EMAIL PROTECTED] wrote: Isn't this just dateItems without the comas. No, because dateItems works only for the 100-year period defined by the centuryCutoff, whereas Sarah's Julian date approach is centuryCutoff-independent. Dave Cragg wrote: I don't think this is a

Re: date anomalies when converting to seconds

The doc statement, 'The dateItems does not change ...[is] an invariant form that won't change' without any reference to a limitation, may have led me down the garden path to think that it didn't suffer from a year XX limit. Thanks for pointing this out. You are most welcome, Kay. Back

Re: date anomalies when converting to seconds

On 5/23/06, Chris Sheffield [EMAIL PROTECTED] wrote: Jim, I owe you an apology. You were correct. This problem is tied to daylight savings. I realized that after taking your advice and looking at the list archives. Fortunately, with some suggestions and code from Sarah Reichelt, I was able to

Re: date anomalies when converting to seconds

On 5/24/06, Sarah Reichelt [EMAIL PROTECTED] wrote: Since it seems unlikely that I will get what I want, I am gradually starting to use my own numeric dateTime format and conversion routines: MMDD, HHMMSS or the 2 combined. As well as being totally numeric which is great for sorting, they

date anomalies when converting to seconds

This is one for those of you developing for both Mac and Windows. I'm running into a very strange problem, and I'm not sure if it's a Rev bug or if it has something to do with hardware differences between Macs and PCs. Here's a code snippet: put 01/06/2006 into tDate convert tDate to

Re: date anomalies when converting to seconds

If you look in the archives, this topic was recently discussed fairly well. The operating systems do date and time and daylight savings differently. This is inherent in each system. If these calculations are critical to your operation, you should invest a bit of time building a small date-time

Re: date anomalies when converting to seconds

Thanks, Jim. However, I'm not totally sure this will really help me, as I'm not really having a problem with daylight savings. The dates I'm dealing with are entered by the user. They are not gotten from the computer's clock. All I am doing is converting these dates to seconds, which is

Re: date anomalies when converting to seconds

On May 22, 2006, at 12:30 PM, Chris Sheffield wrote: The dates I'm dealing with are entered by the user. The bad news is that 'convert' has side effects. It looks at system data and will modify the seconds clock and the time on some platforms and in some conditions. Paranoids build

Re: date anomalies when converting to seconds

Jim, I owe you an apology. You were correct. This problem is tied to daylight savings. I realized that after taking your advice and looking at the list archives. Fortunately, with some suggestions and code from Sarah Reichelt, I was able to workaround the problem, I think. Further

Re: date anomalies when converting to seconds

Very glad you struggled through to a solution for now. It is a road we all have taken. This is the kind of exercise that makes Rev a true tool for the future. Jim Ault Las Vegas On 5/22/06 2:03 PM, Chris Sheffield [EMAIL PROTECTED] wrote: Jim, I owe you an apology. You were correct. This

Re: date anomalies when converting to seconds

On 5/23/06, Jim Ault [EMAIL PROTECTED] wrote: If you look in the archives, this topic was recently discussed fairly well. The operating systems do date and time and daylight savings differently. This is inherent in each system. If these calculations are critical to your operation, you should