Re: Problem with convert it to seconds
Jacque- Friday, April 29, 2005, 7:16:28 PM, you wrote: JLG The script editor is just another stack, so of course when you change JLG stacks the original selection is removed. So this isn't really something JLG that's wrong with Revolution, it is just standard behavior. On the JLG other hand, it is probably something that newcomers wouldn't expect so JLG maybe it should stay in there. Use different wording, maybe. I agree that it isn't necessarily a problem in the IDE, but only in hindsight when you start to analyze what's really going on. It is definitely something that can and will trip people up, so documenting the behavior is, IMO, the right thing to do. And I thought that was one of the purposes of a blog, anyway - documenting the journey so that others coming after won't trip in the same places. If there are actual bugs they belong in bugzilla. JLG Also, the problem with the selection point in newly opened script JLG editors isn't something I can reproduce, so I wonder if it is really JLG related to how the editor is opened. I thought this was an old bug that JLG got fixed. OTOH, *I* can reproduce it here without a problem, and it was a surprise to me... may be a Windows thing - I haven't had a chance to try it yet in OSX. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
It needs more. FD MEEE -- http://taoof4d.blogspot.com http://4dwishlist.blogspot.com On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
Paul, My remark was a kind of understatement... Of course I DO agree... JB JB You kind of agree ? This is an undocumented, non-intuitive way of handling dates and times which will break seconds and dateItem scripts created by non-suspecting users twice a year. How can the Rev. team justify the difficulty of doing what should be a simple process of getting the date for then next day - as late as Version 2.5? Paul Looney -Original Message- From: jbv [EMAIL PROTECTED] To: How to use Revolution use-revolution@lists.runrev.com Sent: Thu, 28 Apr 2005 22:54:18 +0200 Subject: Re: Problem with convert it to seconds Thanks for the help Sarah. Actually I went for a similar solution : as I'm running Rev cgi on a Linux box, I do most of the time computations through MySQL... Sarah, You can not rant often enough about Rev.'s time peculiarities! This is an undocumented time bomb waiting for evey new user. It should have been fixed at least two years ago. PL I kind of agree with that... JB ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
I have a further problem with the seconds which I will describe in case anyone else finds it a problem. It reports the number of seconds since midnight on 1/1/1970 GMT. The fact that it is GMT is crucial as it means that the number returned by the seconds is not an absolute date time but depends on the time zone of the computer that is converting it. For example, I operate a remote computer in a different time zone that logs certain events using time stamps in seconds. It then sends me that log and I convert the time stamps to date time. Because I am in a different time zone, the times change. I am in time zone +1000 and the remote computer is in +0930. A log entry gets added at the remote computer at 5:30 am. It sends me the report and the log entry gets translated as having happened at 6 am. Now it was 6 am for me when it happened, so the seconds is reporting the actual moment in time, but I want to know what the local time was when the event happened, so again I am forced into weird convolutions where I have to allow for differences in time zones whenever data is transferred from a remote machine. While I am stuck using the seconds because other programs depend on getting data in that format, I recommend using another method if at all possible. Julian time would now be my preferred option for a numeric time stamp. Unfortunately, my system originally used HyperCard where a numeric value in seconds ALWAYS translated to the same date time regardless of time zones. If you want to test this, try the following script: put 1113336031 into t convert t to short date and long time put t If I use my local time - Brisbane, Australia (+1000), I get: 4/13/05 6:00:31 AM But if I switch to Adelaide, Australia (+0930), I get: 4/13/05 5:30:31 AM You will get a varying date time depending on your local time zone and current daylight savings setting. While the old HyperCard method failed to take DST into account when needed, when not needed the Rev method fails. I'll toss in my votes for a way to let the developer choose the method most appropriate to the task at hand. What's the Bugzilla #? -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
Richard, You will get a varying date time depending on your local time zone and current daylight savings setting. While the old HyperCard method failed to take DST into account when needed, when not needed the Rev method fails. I'll toss in my votes for a way to let the developer choose the method most appropriate to the task at hand. What's the Bugzilla #? I'm not sure but I wonder if there is any Bugzilla entrie for that... Furthermore, I wonder if my initial problem is related to the time zone problem : as said in my 1st post, I get different results on different platforms which are all in the same time zone... JB ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
JB, It is kind of you to say so. ;-) I hope someone in Scotland is listening to us... Paul Looney -Original Message- From: jbv [EMAIL PROTECTED] To: How to use Revolution use-revolution@lists.runrev.com Sent: Fri, 29 Apr 2005 08:31:40 +0200 Subject: Re: Problem with convert it to seconds Paul, My remark was a kind of understatement... Of course I DO agree... JB JB You kind of agree ? This is an undocumented, non-intuitive way of handling dates and times which will break seconds and dateItem scripts created by non-suspecting users twice a year. How can the Rev. team justify the difficulty of doing what should be a simple process of getting the date for then next day - as late as Version 2.5? Paul Looney -Original Message- From: jbv [EMAIL PROTECTED] To: How to use Revolution use-revolution@lists.runrev.com Sent: Thu, 28 Apr 2005 22:54:18 +0200 Subject: Re: Problem with convert it to seconds Thanks for the help Sarah. Actually I went for a similar solution : as I'm running Rev cgi on a Linux box, I do most of the time computations through MySQL... Sarah, You can not rant often enough about Rev.'s time peculiarities! This is an undocumented time bomb waiting for evey new user. It should have been fixed at least two years ago. PL I kind of agree with that... JB ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
I just put this on the TAO of RunRev blog. If y'all would email me, too, I'd get this posted faster. -- http://taoof4d.blogspot.com http://4dwishlist.blogspot.com On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
I just put this on the TAO of RunRev blog. If y'all would email me, too, I'd get this posted faster. I hope someone in Scotland is listening to us... Paul Looney Has anyone posted this enhancement request for optional DST-independent time calculations to Bugzilla? What's the BZ report number? -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
In the interim, it still, IMHO needs to be on the Tao blog. The reason is that it is an unexpected behavior (despite the fact that it's documented). So, when y'all have things like this that come up I'd still like to know about them so I can get them on the list. -- http://taoof4d.blogspot.com http://4dwishlist.blogspot.com On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
Oops, sorry, I have the wrong blogs in the sig. http://www.taoofrunrev.blogspot.com -- http://taoof4d.blogspot.com http://4dwishlist.blogspot.com On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
Richard- Friday, April 29, 2005, 8:18:48 AM, you wrote: RG Has anyone posted this enhancement request for optional DST-independent RG time calculations to Bugzilla? RG What's the BZ report number? I coulda sworn this was in bz, but the closest I could come was #2387, still categorized as new, even after the note from tuviah confirming the bug. So I threw five votes that way in the hopes that the engine team will wake up and spend time fixing the date routines so that we can stop bringing it up on the list. Anyone else for making #2387 the focal point for this? -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
I hope someone in Scotland is listening to us... Paul Looney We listen. Sometimes we even respond... And if the discussion gets out of hand I'll pop up and look stern :) But, and you can all sing along with me here ladies and gentlemen, if you want action, you need to post it to bugzilla: http://support.runrev.com/bugzilla This is your list, we observe but we do not intervene very often, and you should not assume that items reported here will make it onto the engineering fix list. And by the way, I'd like to congratulate everyone present on the fascinating, excellent and mature discussion sparked by what was potentially a very inflammatory post on philosophy. As you all know, wine, cheese and politics are off topic and frowned on, we can now add philosophy to that list :) Warm regards Heather Sometimes listmom, always supportive -- ** For a faster response to all licensing, support, and technical issues, please now send mail to [EMAIL PROTECTED] ** Heather Nagey ~ [EMAIL PROTECTED] ~ http://www.runrev.com/ Runtime Revolution - User-Centric Development Tools Tel +44 (0) 870 747 1165 Fax +44 (0) 845 4588487 ~~~ Check our web site for new Revolution editions special offers ~~~ ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
On 4/29/05 11:38 AM, Mark Wieder [EMAIL PROTECTED] wrote: Richard- Friday, April 29, 2005, 8:18:48 AM, you wrote: RG Has anyone posted this enhancement request for optional DST-independent RG time calculations to Bugzilla? RG What's the BZ report number? I coulda sworn this was in bz, but the closest I could come was #2387, still categorized as new, even after the note from tuviah confirming the bug. So I threw five votes that way in the hopes that the engine team will wake up and spend time fixing the date routines so that we can stop bringing it up on the list. Anyone else for making #2387 the focal point for this? Yes, that sounds good. In fact, one thing that people are interested in is a simple example of the problem at hand. Here is what I consider to be a simple example of the conversion issue (keep in mind that this year in the US, DST happened on 4/3/05 Spring Forward, and will happen again on 10/30/05 Fall Back): - Date *before* Spring DST changeover - put 4/1/2005 05:00 into tDate convert tDate to seconds convert tDate to short date and short time put tDate -- 4/1/05 4:00 - Date between Spring and Fall DST changes put 4/29/2005 05:00 into tDate convert tDate to seconds convert tDate to short date and short time put tDate -- 4/29/05 5:00 - Date *after* Fall DST changeover - put 11/1/2005 05:00 into tDate convert tDate to seconds convert tDate to short date and short time put tDate -- 11/1/05 4:00 As you can see, it all has to do with what side of DST you're on. If you ask for the conversion to handle a date on this side of DST (i.e. you ask for a date between 4/3 and 10/30 when the current system clock also registers a date between 4/3 and 10/30), everything's OK. If, on the other hand, you ask for a date that is on the other side of DST (i.e. you ask for a date between 10/31 and 4/2 when the current system clock registers a date between 4/3 and 10/30), you lose an hour. There are obviously other date/time conversion issues, but this helps to provide a simple example everyone can grok. I have suggested a new useDST global property to put the conversion choice in the hands of the developer, and have added 5 of my votes to this. I strongly recommend that people pour their votes on this bug so we can get it fixed ASAP. Thanks, Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
Mikey- I finally took a look at the blog. That's getting to be quite a collection. Thanks for putting that together. -- -Mark Wieder [EMAIL PROTECTED] Friday, April 29, 2005, 8:55:43 AM, you wrote: M Oops, sorry, I have the wrong blogs in the sig. M http://www.taoofrunrev.blogspot.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
On 4/29/05 5:09 PM, Mark Wieder wrote: Mikey- I finally took a look at the blog. That's getting to be quite a collection. Thanks for putting that together. Good start, yes. Good work Mikey. A couple of them don't feel quite right though. I'm not sure whether they should be left alone because they are common things that might trip up newcomers, or if they should be corrected because they aren't really problems. For example, this one: debugger affects the execution of some scripts Try the following script in a field: on tabKey answer the selectedChunk end tabKey Now click in the field and type a character. Notice the answer that results. Now edit the script, and set a debug checkpoint either on the on tabKey or answer... lines. Exit the script, click in the field, and type a character. Surprise! The answer dialog is empty. The script editor is just another stack, so of course when you change stacks the original selection is removed. So this isn't really something that's wrong with Revolution, it is just standard behavior. On the other hand, it is probably something that newcomers wouldn't expect so maybe it should stay in there. Use different wording, maybe. Also, the problem with the selection point in newly opened script editors isn't something I can reproduce, so I wonder if it is really related to how the editor is opened. I thought this was an old bug that got fixed. The blog is a good idea though Mikey, keep going. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
Sarah, You can not rant often enough about Rev.'s time peculiarities! This is an undocumented time bomb waiting for evey new user. It should have been fixed at least two years ago. PL -Original Message- From: Sarah Reichelt [EMAIL PROTECTED] To: How to use Revolution use-revolution@lists.runrev.com Sent: Thu, 28 Apr 2005 14:34:37 +1000 Subject: Re: Problem with convert it to seconds When using the convert function in Rev cgi Linux and in Rev Mac OS9 (or Win XP) I get different results : - Rev cgi : 1114427491 - Rev Win XP : 1114423891 There's a 3600 seconds difference, and I vaguely remember a discussion (in the old MC days) about the fact that the cgi engine calling a unix convert function that doesn't take into account the summer / winter time change... Anyone has some info about this (or a workaround) ? WARNING: long rant about Rev's time handling!! I have only encountered this on Mac OS X but it is a real problem. I can confirm that it happens, but the only solution I worked out used AppleScript. There may be a Unix method you could use, so I'll explain what I do. In Rev, I use the internet date to give me the time zone (it's the last word), then I use AppleScript to give me the number of minutes to GMT. AppleScript gives me the time zone INCLUDING any daylight savings component, rev's gives me the time zone ignoring daylight saving. I then use the difference between these 2 to get the current amount of daylight savings time, so I can apply this as necessary. I have a further problem with the seconds which I will describe in case anyone else finds it a problem. It reports the number of seconds since midnight on 1/1/1970 GMT. The fact that it is GMT is crucial as it means that the number returned by the seconds is not an absolute date time but depends on the time zone of the computer that is converting it. For example, I operate a remote computer in a different time zone that logs certain events using time stamps in seconds. It then sends me that log and I convert the time stamps to date time. Because I am in a different time zone, the times change. I am in time zone +1000 and the remote computer is in +0930. A log entry gets added at the remote computer at 5:30 am. It sends me the report and the log entry gets translated as having happened at 6 am. Now it was 6 am for me when it happened, so the seconds is reporting the actual moment in time, but I want to know what the local time was when the event happened, so again I am forced into weird convolutions where I have to allow for differences in time zones whenever data is transferred from a remote machine. While I am stuck using the seconds because other programs depend on getting data in that format, I recommend using another method if at all possible. Julian time would now be my preferred option for a numeric time stamp. Unfortunately, my system originally used HyperCard where a numeric value in seconds ALWAYS translated to the same date time regardless of time zones. If you want to test this, try the following script: put 1113336031 into t convert t to short date and long time put t If I use my local time - Brisbane, Australia (+1000), I get: 4/13/05 6:00:31 AM But if I switch to Adelaide, Australia (+0930), I get: 4/13/05 5:30:31 AM You will get a varying date time depending on your local time zone and current daylight savings setting. Cheers, Sarah ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
Thanks for the help Sarah. Actually I went for a similar solution : as I'm running Rev cgi on a Linux box, I do most of the time computations through MySQL... Sarah, You can not rant often enough about Rev.'s time peculiarities! This is an undocumented time bomb waiting for evey new user. It should have been fixed at least two years ago. PL I kind of agree with that... JB ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
JB You kind of agree ? This is an undocumented, non-intuitive way of handling dates and times which will break seconds and dateItem scripts created by non-suspecting users twice a year. How can the Rev. team justify the difficulty of doing what should be a simple process of getting the date for then next day - as late as Version 2.5? Paul Looney -Original Message- From: jbv [EMAIL PROTECTED] To: How to use Revolution use-revolution@lists.runrev.com Sent: Thu, 28 Apr 2005 22:54:18 +0200 Subject: Re: Problem with convert it to seconds Thanks for the help Sarah. Actually I went for a similar solution : as I'm running Rev cgi on a Linux box, I do most of the time computations through MySQL... Sarah, You can not rant often enough about Rev.'s time peculiarities! This is an undocumented time bomb waiting for evey new user. It should have been fixed at least two years ago. PL I kind of agree with that... JB ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Problem with convert it to seconds
When using the convert function in Rev cgi Linux and in Rev Mac OS9 (or Win XP) I get different results : - Rev cgi : 1114427491 - Rev Win XP : 1114423891 There's a 3600 seconds difference, and I vaguely remember a discussion (in the old MC days) about the fact that the cgi engine calling a unix convert function that doesn't take into account the summer / winter time change... Anyone has some info about this (or a workaround) ? WARNING: long rant about Rev's time handling!! I have only encountered this on Mac OS X but it is a real problem. I can confirm that it happens, but the only solution I worked out used AppleScript. There may be a Unix method you could use, so I'll explain what I do. In Rev, I use the internet date to give me the time zone (it's the last word), then I use AppleScript to give me the number of minutes to GMT. AppleScript gives me the time zone INCLUDING any daylight savings component, rev's gives me the time zone ignoring daylight saving. I then use the difference between these 2 to get the current amount of daylight savings time, so I can apply this as necessary. I have a further problem with the seconds which I will describe in case anyone else finds it a problem. It reports the number of seconds since midnight on 1/1/1970 GMT. The fact that it is GMT is crucial as it means that the number returned by the seconds is not an absolute date time but depends on the time zone of the computer that is converting it. For example, I operate a remote computer in a different time zone that logs certain events using time stamps in seconds. It then sends me that log and I convert the time stamps to date time. Because I am in a different time zone, the times change. I am in time zone +1000 and the remote computer is in +0930. A log entry gets added at the remote computer at 5:30 am. It sends me the report and the log entry gets translated as having happened at 6 am. Now it was 6 am for me when it happened, so the seconds is reporting the actual moment in time, but I want to know what the local time was when the event happened, so again I am forced into weird convolutions where I have to allow for differences in time zones whenever data is transferred from a remote machine. While I am stuck using the seconds because other programs depend on getting data in that format, I recommend using another method if at all possible. Julian time would now be my preferred option for a numeric time stamp. Unfortunately, my system originally used HyperCard where a numeric value in seconds ALWAYS translated to the same date time regardless of time zones. If you want to test this, try the following script: put 1113336031 into t convert t to short date and long time put t If I use my local time - Brisbane, Australia (+1000), I get: 4/13/05 6:00:31 AM But if I switch to Adelaide, Australia (+0930), I get: 4/13/05 5:30:31 AM You will get a varying date time depending on your local time zone and current daylight savings setting. Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Problem with convert it to seconds
Hi list, When using the convert function in Rev cgi Linux and in Rev Mac OS9 (or Win XP) I get different results : - Rev cgi : 1114427491 - Rev Win XP : 1114423891 There's a 3600 seconds difference, and I vaguely remember a discussion (in the old MC days) about the fact that the cgi engine calling a unix convert function that doesn't take into account the summer / winter time change... Anyone has some info about this (or a workaround) ? Thanks, JB ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
