SQL Date Formatting
Kay C Lan
lan.kc.macmail at gmail.com
Sat Jan 14 05:09:53 CST 2012
On Sat, Jan 14, 2012 at 1:07 AM, Ken Ray <kray at sonsothunder.com> wrote:
> Just a little 'gotcha' here - I've been doing A LOT with dates and times
> recently, and discovered that you either need to make sure the
> 'useSystemDate' is set to true in your code, OR make sure to add the
> "system" keyword in any format conversion, otherwise it assumes
> US-formatted dates (this is documented in Bug #9893 in Bugzilla). Here's an
nice catch, and I see looking into a bunch of my date/time manipulation
functions that the very first line is:
set the userSystemDate to true
Obviously a long time back I read this Dictionary entry:
Use the useSystemDate property to correctly format dates and times that
> will be viewed by the user (for example, dates and times that are displayed
> in a field).
and took it's advise and left LC to do all the conversion because I spend a
lot of time displaying and retrieving date/time :-)
I read Bug #9893 and agree with Ian's comment that this is not a bug, and
appreciate, with understanding I didn't have before, that this is a
'feature' that can be exploited depending on what you are doing.
If you are NOT displaying dates/times to a user*, then there is no need to
set the userSystemDate, and regardless of OS, country or custom settings,
internally LC will always use the US format. This WILL save code because
now I know I don't need to worry about converting just to be sure which
numbers are months, days and is it 12 or 24hr time.
On the other hand, if I'm going to display the date/time or allow users to
input them*, then ensuring the userSystemDate is set to true in every
handler that deals with date/time, will allow LC to do it's thing and
display date/time as the User expects to see them.
* Working with the OS file system creation/modified/opened date/time would
need the userSystemDate to be set to true.
Thanks for the insight.
More information about the use-livecode