Re: HELP WITH DATES

This WebDNA talk-list message is from

1997


It keeps the original formatting.
numero = 10479
interpreted = N
texte = >>Will it be able to deal with my preferred YEAR/MONTH/DAY format (as in >>1997/04/23) instead of just understanding MONTH/DAY/YEAR? > >It looks at the preferences for date format (which until now has only >referred to your preference for OUTPUT) and deduces from that what the >date input format should be.Okay, this would solve any problems I might have in using my own date format on my site.>>How is it going to detect whether or not there's a date in the math >>context? In other words, what's it looking for that makes it decide that >>it's dealing with a date instead of a text string? Just the slashes? Or two >>slashes separated by two other characters? or ??? > >It looks for sequences of numbers like xx/xx/xx and assumes that is a >date. So you _cannot_ create a math context that has 2 divisions in a >row. If you use parentheses you could create the 2 divisions.This seems relatively painless to me, and it lets WebDNA recognize a date in its common format, which is the way *most* people will want to store their dates.Just for a point of fact, I almost decided to store my dates in a 'no delimiter' format (you know, by *not* using slashes or anything else to separate the digits) - becasue it would save space in the database. I assume WebDNA would have been able to recognize an 8-digit string of numbers as a date, even without any delimiters, because that's how my date format would have been set in the prefs. But I didn't actually try it to see whether or not it would work, so I don't know for sure.One thing is for sure, and that's the fact that if I *had* used any delimiter other than slashes - including none at all - your proposal for identifying dates by the double slashes in a [math] context would not have worked for me.>I am leaning toward a WebDNA assumption that if there's a date in the math >context anywhere, then it is assumed that the results of the math context >will look like a date instead of a number. > >[math]12/3[/math] yields 4 >[math]12/3/96+1[/math] yields 12/4/96 >[math]12/3/96+0/0/1[/math] yields 12/3/97>The whole idea here is to make the syntax for date manipulation a lot easier.This looks good to me - easy to understand and *not* confusing at all. However, I agree with Jim Shaughnessy that subtracting one date from another to get a signed integer is a common practice and is something that should be taken into consideration. This is good: subtracting one date from another date, resulting in a signed integer adding an integer to a date, resulting in a date subtracting an integer from a date, resulting in a dateBut I do *not* like the idea of putting dates into special brackets, and I don't think it's necessary. You can make WebDNA look for *two* strings with slashes in them, and when it finds those two strings (on either side of a minus sign, for example) it formats the results into a signed integer. Any other math using dates would be date formatted.Sincerely, Ken ------------------------------------ To leave this talk list send an email to macjordomo@smithmicro.com with BODY unsubscribe WebDNA-Talk ------------------------------------ Associated Messages, from the most recent to the oldest:

    
  1. Re: Help with dates (John Peacock 2001)
  2. Re: Help with dates (Gorana Leahy 2001)
  3. Re: Help with dates (Gorana Leahy 2001)
  4. Re: Help with dates (John Peacock 2001)
  5. Re: Help with dates (Will Starck 2001)
  6. Re: Help with dates (John Peacock 2001)
  7. Re: Help with dates (Tom Duke 2001)
  8. Re: Help with dates (Tom Duke 2001)
  9. Re: Help with dates (Gorana Leahy 2001)
  10. Re: Help with dates (John Peacock 2001)
  11. Help with dates (Gorana Leahy 2001)
  12. Re: HELP WITH DATES (Kenneth Grome 1997)
  13. Re: HELP WITH DATES (Jim Shaughnessy 1997)
  14. Re: HELP WITH DATES (John Hill 1997)
  15. Re: HELP WITH DATES (grichter@panavise.com (Gary Richter) 1997)
  16. Re: HELP WITH DATES (Jim Shaughnessy 1997)
  17. Re: HELP WITH DATES (Grant Hulbert 1997)
  18. Re: HELP WITH DATES (Kenneth Grome 1997)
  19. HELP WITH DATES (John Hill 1997)
>>Will it be able to deal with my preferred YEAR/MONTH/DAY format (as in >>1997/04/23) instead of just understanding MONTH/DAY/YEAR? > >It looks at the preferences for date format (which until now has only >referred to your preference for OUTPUT) and deduces from that what the >date input format should be.Okay, this would solve any problems I might have in using my own date format on my site.>>How is it going to detect whether or not there's a date in the math >>context? In other words, what's it looking for that makes it decide that >>it's dealing with a date instead of a text string? Just the slashes? Or two >>slashes separated by two other characters? or ??? > >It looks for sequences of numbers like xx/xx/xx and assumes that is a >date. So you _cannot_ create a math context that has 2 divisions in a >row. If you use parentheses you could create the 2 divisions.This seems relatively painless to me, and it lets WebDNA recognize a date in its common format, which is the way *most* people will want to store their dates.Just for a point of fact, I almost decided to store my dates in a 'no delimiter' format (you know, by *not* using slashes or anything else to separate the digits) - becasue it would save space in the database. I assume WebDNA would have been able to recognize an 8-digit string of numbers as a date, even without any delimiters, because that's how my date format would have been set in the prefs. But I didn't actually try it to see whether or not it would work, so I don't know for sure.One thing is for sure, and that's the fact that if I *had* used any delimiter other than slashes - including none at all - your proposal for identifying dates by the double slashes in a [math] context would not have worked for me.>I am leaning toward a WebDNA assumption that if there's a date in the math >context anywhere, then it is assumed that the results of the math context >will look like a date instead of a number. > >[math]12/3[/math] yields 4 >[math]12/3/96+1[/math] yields 12/4/96 >[math]12/3/96+0/0/1[/math] yields 12/3/97>The whole idea here is to make the syntax for date manipulation a lot easier.This looks good to me - easy to understand and *not* confusing at all. However, I agree with Jim Shaughnessy that subtracting one date from another to get a signed integer is a common practice and is something that should be taken into consideration. This is good: subtracting one date from another date, resulting in a signed integer adding an integer to a date, resulting in a date subtracting an integer from a date, resulting in a dateBut I do *not* like the idea of putting dates into special brackets, and I don't think it's necessary. You can make WebDNA look for *two* strings with slashes in them, and when it finds those two strings (on either side of a minus sign, for example) it formats the results into a signed integer. Any other math using dates would be date formatted.Sincerely, Ken ------------------------------------ To leave this Talk List send an email to macjordomo@smithmicro.com with BODY unsubscribe WebDNA-Talk ------------------------------------ Kenneth Grome

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

[index] (1997) 4.0 image uploading /features (2000) File Security (1999) [WebDNA] Converting minutes to hours (2008) Re2: Calculating multiple shipping... (1997) "+" in math context (2004) HomePage Caution (1997) WebCatalog/Mac 2.1b2 New Features (1997) Adding up line items. (2000) webcat restarting script on Linux? (1999) Can't ping (problem with [shell]) (2006) Searching a field and returning the highest value (1997) how do I have html files routed through webcat on OSX? (2001) bug in [SendMail] (1997) Re:Emailer and encryption (1997) Referrer field to header field conversion (1997) taxTotal, grandTotal (1997) database paths/names, and a typo (1997) fieldType=num (1997) Multiple prices (1997)