Re: BUG in CONVERT command - or I can't tell the time
On Monday, April 22, 2002, at 05:53 AM, Michael D Mays wrote: > When it is 12 midnight in Edinburgh (GMT) it is 6:00 PM the day > before here > in Dallas (CST) (no daylight savings time). I haven't been reading my mail well, Michael. When I read Ian's mail the first time I thought he was complaining that he didn't get the offset. When I read your's I thought you said he shouldn't. My cryptic one line response was not up to the job and your description did well. > IMO, date and time formats should only be used to display dates > and times. > Aside from formatting issues, as illustrated here time and date > formats have > 'hidden parameters' such as where (time zone) and when (daylight > savings > time) associated with them. Daylight savings time seems to be applied in an interesting manner. It seems it is applied if the time is in daylight savings time at the moment of calculation rather than the time/date being converted, even for the current year. To do otherwise might be very hard, especially for future years, when the rules might have changed even again. It would be nice if these hidden parameters could optionally be supplied. How does one get the time zone and daylight savings settings? Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: BUG in CONVERT command - or I can't tell the time
When it is 12 midnight in Edinburgh (GMT) it is 6:00 PM the day before here in Dallas (CST) (no daylight savings time). And that is the way it should be. If a child was born at zero seconds, okay 1 second, in Edinburgh a year later in Dallas at 6:00:01 PM on Dec 31st she would be a year old. IMO, date and time formats should only be used to display dates and times. Aside from formatting issues, as illustrated here time and date formats have 'hidden parameters' such as where (time zone) and when (daylight savings time) associated with them. If you use time and date formats to to calculate time differences you will find several glitches in your calculations. Daylight savings time can add and subtract an hour and even give you a negative time (which can be particularly troublesome). Using the additional 'system' parameter doesn't solve these problems. Use seconds or dateItems to store and calculate your dates and times if you need to do calculations with them. Note, dateItems records the date and time information as local. michael Dar Scott of [EMAIL PROTECTED] wrote the following on 4/21/02 10:00 PM > On Sunday, April 21, 2002, at 08:18 PM, Michael D Mays wrote: > >> That is what the documentation says. 0 seconds is 12 midnight, Jan >> 1, 1970 >> GMT. > > I get 6:00 PM > > (I was sure 0 used to get an error for me, too, I'm not sure what's > up with that.) ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: BUG in CONVERT command - or I can't tell the time
> Put 21600 into xxx > Convert xxx to short time try instead: convert xxx to short system time ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: BUG in CONVERT command - or I can't tell the time
On Sunday, April 21, 2002, at 08:18 PM, Michael D Mays wrote: > That is what the documentation says. 0 seconds is 12 midnight, Jan > 1, 1970 > GMT. I get 6:00 PM (I was sure 0 used to get an error for me, too, I'm not sure what's up with that.) Look at at the original time header in the mail an you will see my time zone is -600. So for me on OS X 10.1.3, Blue & White, Revolution 1.1.1, convert peeks at the current time zone. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: BUG in CONVERT command - or I can't tell the time
That is what the documentation says. 0 seconds is 12 midnight, Jan 1, 1970 GMT. Or at least close to it. There are discrepancies with convert for zero(s) seconds and -1 seconds. -2 secs -> 23:59:59 -1 secs -> 12:00:00 mid GMT -0 secs -> 12:00:00 mid GMT zero secs -> 0 (the result = invalid date) 0 secs -> 0 (the result = invalid date) +0 secs -> 12:00:00 mid GMT 1 secs -> 12:00:01 get 0 -- and so on convert it to long time put it&&the result michael Ian Summerfield of [EMAIL PROTECTED] wrote the following on 4/21/02 4:25 PM > Maybe this only goes wrong under OS X. I'm using OS X 10.1.4. Maybe this > only goes wrong depending on your date and time setting, I'm set to time > zone "United Kingdom" and my system indicates BST. > > Revolution is ONE hour out with it's results using CONVERT, I think they > have based something on GMT. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: BUG in CONVERT command - or I can't tell the time
On Sunday, April 21, 2002, at 03:25 PM, Ian Summerfield wrote: > My code used to work when we were on GMT, so no doubt it has > something to > do with the engine ignoring time zone settings. Your email shows +100 in the (original) date field, so I assume OS X knows BST. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
BUG in CONVERT command - or I can't tell the time
Maybe this only goes wrong under OS X. I'm using OS X 10.1.4. Maybe this only goes wrong depending on your date and time setting, I'm set to time zone "United Kingdom" and my system indicates BST. Revolution is ONE hour out with it's results using CONVERT, I think they have based something on GMT. In the message box type: Put 21600 into xxx Convert xxx to short time Xxx Xxx contains 7:00; BUT that should be 6:00. I get 6 from: 21600 seconds / 60 = 360 minutes 360 minutes / 60 = 6 hours Now where did it get 7 from? I don't see any mod function around to blame (joke). My code used to work when we were on GMT, so no doubt it has something to do with the engine ignoring time zone settings. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution