Sometimes it can be tempting to display dates manually in your applications -- but please resist! REALbasic provides you with a Date object, and that Date object knows how to properly convert into a string that users will expect and appreciate. Most programmers don't know all of the ins and outs of date formatting (I know I certainly don't!), and will end up getting things wrong.
Many programmers understand that the order of the information depends heavily on the locale. For instance, is 01/02/07 January 02, 2007? Or February 01, 2007? Well, that depends entirely on the user's locale settings. What's more, chances are very good that the month names aren't January or February either! However, that's not the only thing you have to worry about when displaying date information. Take, for instance, genitive dates. "Genitive" refers to possession, and in English, we don't differentiate between the genitive form of a date and the non-genitive form. For instance, we say "March twenty-sixth" or "the twenty-sixth of March" -- in either case, the month name is still "March." However, that's not the case in all languages. In some locales, the genitive month name is actually displayed differently than the non-genitive case. For instance, in Czech, the month name for April on its own is "duben", while the genitive form of April is "dubna."
So, what does this mean for you as a programmer? It means you should never try to display your own dates to the user without using the appropriate OS API or REALbasic API. You can use Date.LongDate (or whatever) to get the appropriate format. But if you find that you need to display something in a format that REALbasic doesn't supply, then the only proper way to do it is via an OS API like GetDateFormat (on Windows). Otherwise, you're certain to miss one of the many date formatting subtleties.
My main beef with the date object is that Parsedate only parses the localized date, not any valid date. :(
Well yeah, of course it works that way... :-) Could you imagine the pure craziness it would be to try to parse arbitrary dates without any locale information? What would this return for a date: "01/02/07"? Is that Jan? Feb? July? And so on. Basically, the ability to parse a date *requires* locale information.
It might be useful if you could specify the format of the date. Thus, if you had "01/02/07", you could convert it normally using local information, or you could specify the local, if you *know* already the format.
But, if you already know the format -- why don't you parse it yourself? It's not a complex operation. The hard part is knowing what format the string is in.
Yes, I can understand where you're coming from. The thing is, that is makes it nearly impossible to allow a free form date field. :(
The nearest I've got to free-form date parsing is at
http://rb.sgarman.net/validDate.php
"that is makes it nearly impossible to allow a free form date field."
Free form date parsing IS impossible, simply because of the conflicting date formats used throughout the world.
Am I wrong thinking there is only two dates formats:
a. everyone except USA: Day, Month, Year
b. USA: Month, Day, Year
?
@Emile -- yup, there are other formats. Some countries do the year first. Also, you have to keep in mind that some countries don't use gregorian calendars (such as the chinese lunar calendar), some calendars have 13 months instead of 12, and so on. The "format" of the date is more than just day, month and year order -- it's also the information such as whether the year is gregorian, julian, and so on (etc).
I whipped up a function using WFS to get the system's format into a PHP date()-like syntax and then parse the date and time (SG's function only parses date) according to this format string. With a little tweak this would be easy to change to allow any format string instead of building it from the system's localized settings. Feel free to PM me on the forums ("msa") to get a copy of the function.