date fields

[Jean Vallee]

I have file with several date fields. Some were filled in when I converted. All date fields are formatted mm/0d/yyyy. The fields that were already filled in at conversion display properly. However, when I try to fill in an empty date field with 01202000, it does not convert/display it as 01/20/2000 and gives the error message: ERROR RETRIEVING THE FIELD VALUE FROM THE TEXT YOU ENTERED. Is this the way it is supposed to be? Jean Vallee

[Michael]

On 15/01/2013 20:39, JV wrote:
> I have file with several date fields. Some were filled in when I converted.
>
> All date fields are formatted mm/0d/yyyy.
>
> The fields that were already filled in at conversion display properly.
>
> However, when I try to fill in an empty date field with 01202000, it
> does not convert/display it as 01/20/2000 and gives the error message:
>
> ERROR RETRIEVING THE FIELD VALUE FROM THE TEXT YOU ENTERED.
>
> Is this the way it is supposed to be?

If you enter a date without any separators, it assumes that an 8-digit date is entered in yyyymmdd format. It may be that
assumption should be corrected, but it has not been an issue until now.

Ciao, Neil

[JD Kromkowski]

There could just be an easy check put into Simpol's date handling:

ie

if first 4 digits are less than 1231
then date is in mmddyyyy form

The bottom line, in my opinion, is that the date handling function
should be able to accept all formats that Simpol's display format
allows. Because the display format dialog allows for 0m0dYYYY, you need
to accept that as a possible text entry.

The same is true for times:

For example, my pet peeve which I haven't mentioned because I am already
a pest:

if I enter "9 30"

the time handling function should be able to parse this and make it
"9:30 am" if the display format is "hh:mm am".

Why? Well first because Superbase did and I have developed a bad habit
of enter that way to avoid shft key to get to ":"

And I still don't think the time handler is working correctly

for "9:30 am"

is should be able to enter

0930
930
09 30
9 30
0930 am
930 am
9 30 am
09 30 am
09:30
9:30
09:30 am
9:30 am
etc.

and part of the problem is that there is definatly a bug in the modify
table thing when in comes to display formats.

On 01/23/13 7:47 AM, Neil Robinson wrote:
> On 15/01/2013 20:39, JV wrote:
>> I have file with several date fields. Some were filled in when I converted.
>>
>> All date fields are formatted mm/0d/yyyy.
>>
>> The fields that were already filled in at conversion display properly.
>>
>> However, when I try to fill in an empty date field with 01202000, it
>> does not convert/display it as 01/20/2000 and gives the error message:
>>
>> ERROR RETRIEVING THE FIELD VALUE FROM THE TEXT YOU ENTERED.
>>
>> Is this the way it is supposed to be?
>
> If you enter a date without any separators, it assumes that an 8-digit date is entered in yyyymmdd format. It may be that
> assumption should be corrected, but it has not been an issue until now.
>
> Ciao, Neil
>

[Michael]

On 24/01/2013 17:26, kromkowski wrote:
> There could just be an easy check put into Simpol's date handling:
>
> ie
>
> if first 4 digits are less than 1231
> then date is in mmddyyyy form
>
>
> The bottom line, in my opinion, is that the date handling function
> should be able to accept all formats that Simpol's display format
> allows. Because the display format dialog allows for 0m0dYYYY, you need
> to accept that as a possible text entry.
>
> The same is true for times:
>
> For example, my pet peeve which I haven't mentioned because I am already
> a pest:
>
> if I enter "9 30"
>
> the time handling function should be able to parse this and make it
> "9:30 am" if the display format is "hh:mm am".
>
> Why? Well first because Superbase did and I have developed a bad habit
> of enter that way to avoid shft key to get to ":"
>
> And I still don't think the time handler is working correctly
>
> for "9:30 am"
>
> is should be able to enter
>
> 0930
> 930
> 09 30
> 9 30
> 0930 am
> 930 am
> 9 30 am
> 09 30 am
> 09:30
> 9:30
> 09:30 am
> 9:30 am
> etc.
>
> and part of the problem is that there is definatly a bug in the modify
> table thing when in comes to display formats.

What happens when you enter 110?

This sort of auto-guessing what the user meant is a major PITA, to be honest. You can see the code used yourself, it is in the
library projects in source code. Still, I understand where you are coming from. The example I asked about could be interpreted as
1:10, it could also be 11:00. I suppose the logic might be to grab the last 2 digits and then see what is left.

Ciao, Neil

[Michael]

On 24/01/2013 19:44, Neil Robinson wrote:> On 24/01/2013 17:26, kromkowski wrote:
>> There could just be an easy check put into Simpol's date handling:
>>
>> ie
>>
>> if first 4 digits are less than 1231
>> then date is in mmddyyyy form
>>
>>
>> The bottom line, in my opinion, is that the date handling function
>> should be able to accept all formats that Simpol's display format
>> allows. Because the display format dialog allows for 0m0dYYYY, you need
>> to accept that as a possible text entry.
>>
>> The same is true for times:
>>
>> For example, my pet peeve which I haven't mentioned because I am already
>> a pest:
>>
>> if I enter "9 30"
>>
>> the time handling function should be able to parse this and make it
>> "9:30 am" if the display format is "hh:mm am".
>>
>> Why? Well first because Superbase did and I have developed a bad habit
>> of enter that way to avoid shft key to get to ":"
>>
>> And I still don't think the time handler is working correctly
>>
>> for "9:30 am"
>>
>> is should be able to enter
>>
>> 0930
>> 930
>> 09 30
>> 9 30
>> 0930 am
>> 930 am
>> 9 30 am
>> 09 30 am
>> 09:30
>> 9:30
>> 09:30 am
>> 9:30 am
>> etc.
>>
>> and part of the problem is that there is definatly a bug in the modify
>> table thing when in comes to display formats.
>
> What happens when you enter 110?
>
> This sort of auto-guessing what the user meant is a major PITA, to be honest. You can see the code used yourself, it is in the
> library projects in source code. Still, I understand where you are coming from. The example I asked about could be interpreted
> as 1:10, it could also be 11:00. I suppose the logic might be to grab the last 2 digits and then see what is left.
>
> Ciao, Neil
>

I have revisited the algorithms for dates and times being converted from string. I made a few more tweaks and it should cope with
most of what you throw at it. Here are the test cases that work fine:

Date tests:

datelibtestvalue.new(t, 1, " 2004December31", "yyyymmmmdd", 2004, 12, 31)
datelibtestvalue.new(t, 2, " December 31, 2004", "mmmm dd,yyyy", 2004, 12, 31)
datelibtestvalue.new(t, 3, "31.12.2004", "dd.mm.yyyy", 2004, 12, 31)
datelibtestvalue.new(t, 4, "12/31/2004", "mm/dd/yyyy", 2004, 12, 31)
datelibtestvalue.new(t, 5, "12 31 04", "mm dd yy", 2004, 12, 31)
datelibtestvalue.new(t, 6, "31 12 04", "dd mm yy", 2004, 12, 31)
datelibtestvalue.new(t, 7, " 1.01.05", "mm.dd.yy", 2005, 1, 1)
datelibtestvalue.new(t, 8, " 1.01.05", "dd.mm.yy", 2005, 1, 1)
datelibtestvalue.new(t, 9, " 01.1.05", "0m.zd.yy", 2005, 1, 1)
datelibtestvalue.new(t, 10, " 1.1.05", "mm.zd.yy", 2005, 1, 1)
datelibtestvalue.new(t, 11, "01.11.05", "0m.zd.yy", 2005, 1, 11)
datelibtestvalue.new(t, 12, "11.11.05", "zm.zd.yy", 2005, 11, 11)
datelibtestvalue.new(t, 13, " 1.1.05", "zm.zd.yy", 2005, 1, 1)
datelibtestvalue.new(t, 14, " 1.01.05", "zd.0m.yy", 2005, 1, 1)
datelibtestvalue.new(t, 15, "01.01.05", "0m.0d.yy", 2005, 1, 1)
datelibtestvalue.new(t, 16, " 1.Jan.05", "dd.mmm.yy", 2005, 1, 1)
datelibtestvalue.new(t, 17, "Jan.01.05", "mmm.dd.yy", 2005, 1, 1)
datelibtestvalue.new(t, 18, "Jan.01.05", "0mm.dd.yy", 2005, 1, 1)
datelibtestvalue.new(t, 19, "Jan.01.05", "Mmm.dd.yy", 2005, 1, 1)
datelibtestvalue.new(t, 20, " 1 01 2005", "mm, dd yyyy", 2005, 1, 1)
datelibtestvalue.new(t, 21, " 1 Mar 2005", "mm, dd yyyy", 2005, 3, 1)
datelibtestvalue.new(t, 22, " 1 1 5", "dd.mmm.yy", 2005, 1, 1)
datelibtestvalue.new(t, 23, " 1/04.05", "mm, dd yyyy", 2005, 1, 4)
datelibtestvalue.new(t, 24, "010405", "mm, dd yyyy", 2005, 1, 4)
datelibtestvalue.new(t, 25, "01/01/13", "dd/mm/yyyy", 2013, 1, 1)
datelibtestvalue.new(t, 26, "010405", "dd/mm/yy", 2005, 4, 1)
datelibtestvalue.new(t, 27, "010405", "yy/mm/dd", 2001, 4, 5)
datelibtestvalue.new(t, 28, "010405", "0m/0d/yy", 2005, 1, 4)
datelibtestvalue.new(t, 29, "01042005", "0m/0d/yy", 2005, 1, 4)

And here are the time tests:

timelib_s2t_testvalue.new(t, 1, "08:00 pm", "hh:mm am", 20, 0, 0, 0, 0)
timelib_s2t_testvalue.new(t, 2, "08:00 am", "hh:mm am", 8, 0, 0, 0, 0)
timelib_s2t_testvalue.new(t, 3, "08:00 pm", "hh:mm", 20, 0, 0, 0, 0)
timelib_s2t_testvalue.new(t, 4, "08:00 am", "hh:mm", 8, 0, 0, 0, 0)
timelib_s2t_testvalue.new(t, 5, "12:15 am", "hh:mm am", 0, 15, 0, 0, 0)
timelib_s2t_testvalue.new(t, 6, "12:00 pm", "hh:mm am", 12, 0, 0, 0, 0)
timelib_s2t_testvalue.new(t, 7, "01:00 pm", "hh:mm am", 13, 0, 0, 0, 0)
timelib_s2t_testvalue.new(t, 8, "12:30", "hh:mm", 12, 30, 0, 0, 0)
timelib_s2t_testvalue.new(t, 9, "1230", "hh:mm", 12, 30, 0, 0, 0)
timelib_s2t_testvalue.new(t,10, "12", "hh:mm", 12, 0, 0, 0, 0)
timelib_s2t_testvalue.new(t,11, "2", "hh:mm", 2, 0, 0, 0, 0)
timelib_s2t_testvalue.new(t,12, "1303", "hh:mm", 13, 03, 0, 0, 0)
timelib_s2t_testvalue.new(t,13, "acdc", "hh:mm", 0, 0, 0, 0, 0)
timelib_s2t_testvalue.new(t,14, " 34715", "hh:mm:ss", 3, 47,15, 0, 0)
timelib_s2t_testvalue.new(t,15, "12am", "hh:mm", 0, 0, 0, 0, 0)
timelib_s2t_testvalue.new(t,16, "9 30 pm", "hh:mm", 21, 30, 0, 0, 0)
timelib_s2t_testvalue.new(t,17, "930", "hh:mm", 9, 30, 0, 0, 0)
timelib_s2t_testvalue.new(t,18, "9 30", "hh:mm", 9, 30, 0, 0, 0)

Ciao, Neil

[JD Kromkowski]

Well "110" is "1:10 am" because minutes always must have two digits.

I thought I responded earlier. Is what you are testing, what currently
exists in Personal (because it doesn't), or what you are
tweeking/working on for next up date?

The import problem with dates and times, the modify table issues and the
error on handling time and date variations of entered test are all tied
together.

As to "34715", you are too kind. I'd make that a fail. For the same
reason that you must use a "." with milliseconds, one must use a ":" for
seconds. (Oh I see that a space is "allowed" or is defaul for millisecs
the display format but that is wrong in my opinion, you got to use a .
as in ".tt" )

In other words there is no (or "should be no") valid display format as
"hhmmss". You can or have "hhmm:ss" of "hh mm:ss" or "hh:mm:ss". So the
way I'd parse 34715 is

15 must be minutes, "347" is not valid hours entry. So the error
message above the entry box which have the prior entry in it for editing
would be:

347 is not a valid hours enter try again. If you having trouble entering
a time try using "h:mm:ss.tt am" format.

JDK

On 01/24/13 4:59 PM, Neil Robinson wrote:

> Date tests:
>
> datelibtestvalue.new(t, 1, " 2004December31", "yyyymmmmdd", 2004, 12, 31)
> datelibtestvalue.new(t, 2, " December 31, 2004", "mmmm dd,yyyy", 2004, 12, 31)
> datelibtestvalue.new(t, 3, "31.12.2004", "dd.mm.yyyy", 2004, 12, 31)
> datelibtestvalue.new(t, 4, "12/31/2004", "mm/dd/yyyy", 2004, 12, 31)
> datelibtestvalue.new(t, 5, "12 31 04", "mm dd yy", 2004, 12, 31)
> datelibtestvalue.new(t, 6, "31 12 04", "dd mm yy", 2004, 12, 31)
> datelibtestvalue.new(t, 7, " 1.01.05", "mm.dd.yy", 2005, 1, 1)
> datelibtestvalue.new(t, 8, " 1.01.05", "dd.mm.yy", 2005, 1, 1)
> datelibtestvalue.new(t, 9, " 01.1.05", "0m.zd.yy", 2005, 1, 1)
> datelibtestvalue.new(t, 10, " 1.1.05", "mm.zd.yy", 2005, 1, 1)
> datelibtestvalue.new(t, 11, "01.11.05", "0m.zd.yy", 2005, 1, 11)
> datelibtestvalue.new(t, 12, "11.11.05", "zm.zd.yy", 2005, 11, 11)
> datelibtestvalue.new(t, 13, " 1.1.05", "zm.zd.yy", 2005, 1, 1)
> datelibtestvalue.new(t, 14, " 1.01.05", "zd.0m.yy", 2005, 1, 1)
> datelibtestvalue.new(t, 15, "01.01.05", "0m.0d.yy", 2005, 1, 1)
> datelibtestvalue.new(t, 16, " 1.Jan.05", "dd.mmm.yy", 2005, 1, 1)
> datelibtestvalue.new(t, 17, "Jan.01.05", "mmm.dd.yy", 2005, 1, 1)
> datelibtestvalue.new(t, 18, "Jan.01.05", "0mm.dd.yy", 2005, 1, 1)
> datelibtestvalue.new(t, 19, "Jan.01.05", "Mmm.dd.yy", 2005, 1, 1)
> datelibtestvalue.new(t, 20, " 1 01 2005", "mm, dd yyyy", 2005, 1, 1)
> datelibtestvalue.new(t, 21, " 1 Mar 2005", "mm, dd yyyy", 2005, 3, 1)
> datelibtestvalue.new(t, 22, " 1 1 5", "dd.mmm.yy", 2005, 1, 1)
> datelibtestvalue.new(t, 23, " 1/04.05", "mm, dd yyyy", 2005, 1, 4)
> datelibtestvalue.new(t, 24, "010405", "mm, dd yyyy", 2005, 1, 4)
> datelibtestvalue.new(t, 25, "01/01/13", "dd/mm/yyyy", 2013, 1, 1)
> datelibtestvalue.new(t, 26, "010405", "dd/mm/yy", 2005, 4, 1)
> datelibtestvalue.new(t, 27, "010405", "yy/mm/dd", 2001, 4, 5)
> datelibtestvalue.new(t, 28, "010405", "0m/0d/yy", 2005, 1, 4)
> datelibtestvalue.new(t, 29, "01042005", "0m/0d/yy", 2005, 1, 4)
>
>
> And here are the time tests:
>
> timelib_s2t_testvalue.new(t, 1, "08:00 pm", "hh:mm am", 20, 0, 0, 0, 0)
> timelib_s2t_testvalue.new(t, 2, "08:00 am", "hh:mm am", 8, 0, 0, 0, 0)
> timelib_s2t_testvalue.new(t, 3, "08:00 pm", "hh:mm", 20, 0, 0, 0, 0)
> timelib_s2t_testvalue.new(t, 4, "08:00 am", "hh:mm", 8, 0, 0, 0, 0)
> timelib_s2t_testvalue.new(t, 5, "12:15 am", "hh:mm am", 0, 15, 0, 0, 0)
> timelib_s2t_testvalue.new(t, 6, "12:00 pm", "hh:mm am", 12, 0, 0, 0, 0)
> timelib_s2t_testvalue.new(t, 7, "01:00 pm", "hh:mm am", 13, 0, 0, 0, 0)
> timelib_s2t_testvalue.new(t, 8, "12:30", "hh:mm", 12, 30, 0, 0, 0)
> timelib_s2t_testvalue.new(t, 9, "1230", "hh:mm", 12, 30, 0, 0, 0)
> timelib_s2t_testvalue.new(t,10, "12", "hh:mm", 12, 0, 0, 0, 0)
> timelib_s2t_testvalue.new(t,11, "2", "hh:mm", 2, 0, 0, 0, 0)
> timelib_s2t_testvalue.new(t,12, "1303", "hh:mm", 13, 03, 0, 0, 0)
> timelib_s2t_testvalue.new(t,13, "acdc", "hh:mm", 0, 0, 0, 0, 0)
> timelib_s2t_testvalue.new(t,14, " 34715", "hh:mm:ss", 3, 47,15, 0, 0)
> timelib_s2t_testvalue.new(t,15, "12am", "hh:mm", 0, 0, 0, 0, 0)
> timelib_s2t_testvalue.new(t,16, "9 30 pm", "hh:mm", 21, 30, 0, 0, 0)
> timelib_s2t_testvalue.new(t,17, "930", "hh:mm", 9, 30, 0, 0, 0)
> timelib_s2t_testvalue.new(t,18, "9 30", "hh:mm", 9, 30, 0, 0, 0)
>
> Ciao, Neil
>

[Michael]

On 28/01/2013 18:47, kromkowski wrote:
> Well "110" is "1:10 am" because minutes always must have two digits.
>
> I thought I responded earlier. Is what you are testing, what currently
> exists in Personal (because it doesn't), or what you are
> tweeking/working on for next up date?
>
> The import problem with dates and times, the modify table issues and the
> error on handling time and date variations of entered test are all tied
> together.
>
> As to "34715", you are too kind. I'd make that a fail. For the same
> reason that you must use a "." with milliseconds, one must use a ":" for
> seconds. (Oh I see that a space is "allowed" or is defaul for millisecs
> the display format but that is wrong in my opinion, you got to use a .
> as in ".tt" )
>
> In other words there is no (or "should be no") valid display format as
> "hhmmss". You can or have "hhmm:ss" of "hh mm:ss" or "hh:mm:ss". So the
> way I'd parse 34715 is
>
> 15 must be minutes, "347" is not valid hours entry. So the error
> message above the entry box which have the prior entry in it for editing
> would be:
>
> 347 is not a valid hours enter try again. If you having trouble entering
> a time try using "h:mm:ss.tt am" format.

Hi John,

Although your observations make sense for the US (and probably for the UK), there are countries where other characters are
supported for separators. For that reason, you will find that we actually try and completely ignore the separator characters in
our parsing algorithm for dates and times.

As to 110 being 1:10 am, that works fine, but it would never be 1:10 pm. That is one of the reasons why entering times this way
can be error-prone.

The test list is the current test list after tweaking the libraries. These tests are part of my standard library and use the
unittest object which is supplied as a library.

Ciao, Neil

[JD Kromkowski]

Yes, 110 would NEVER be 1:10 pm, it would always parse to 1:10 am.

My points are not limited to the US or the UK.

For whatever display format, SIMPOL allows in theory, then you have to
be able to parse text entered in an allowable format.

The first issue is that right now, at least in personal, you can only
enter text in a format that corresponds to the current display format.
(Because the modify table does quite work correctly; this is a bug.)

The second issue is time parsing function in general.

Simpol allows: "hh mm" as a potential display format, therefore the
parser must be able to parse something entered in that format –
regardless of what the current display format is. So if I enter, "9 30",
then the time value for "9:30 am" has to be stored. Not an error telling
me to reenter or worse no error at all and the leaving of the field blank.

"hhmm" is also an acceptable display format. So if I enter "110", then
you got to be able to handle that entry and resolve it – in this case
it must be resolved to the timevalue for "1:10 am"

As to ignoring separators, well I don't see how you do that with
milliseconds. You can't have milliseconds without a decimal separator.
And in fact Simpol does not allow you to willy nilly pick a different
separator for milliseconds. Either it is going to be the dot . Or you'd
also accept the "," for the decimal in Brazil, Germany, Netherlands,
Denmark, Italy, Portugal, Romania, Sweden, Slovenia, Greece, Switzerland
and much of Europe. And for Arabic there is a Arabic Decimal separator
in Unicode. And for Persian there is Momayyez, which looks a lot like
the comma or forward slash.

Simpol did not invent this issue. And I'd think there would have
standardizes way to handle this.

http://en.wikipedia.org/wiki/Date_format_by_country

This has pretty good parsers based on number of digits:

http://www.cpearson.com/excel/DateTimeEntry.htm

Of course, then there is the Thai six hour clock.

JDK

On 01/29/13 11:39 AM, Neil Robinson wrote:
> On 28/01/2013 18:47, kromkowski wrote:
>> Well "110" is "1:10 am" because minutes always must have two digits.
>>
>> I thought I responded earlier. Is what you are testing, what currently
>> exists in Personal (because it doesn't), or what you are
>> tweeking/working on for next up date?
>>
>> The import problem with dates and times, the modify table issues and the
>> error on handling time and date variations of entered test are all tied
>> together.
>>
>> As to "34715", you are too kind. I'd make that a fail. For the same
>> reason that you must use a "." with milliseconds, one must use a ":" for
>> seconds. (Oh I see that a space is "allowed" or is defaul for millisecs
>> the display format but that is wrong in my opinion, you got to use a .
>> as in ".tt" )
>>
>> In other words there is no (or "should be no") valid display format as
>> "hhmmss". You can or have "hhmm:ss" of "hh mm:ss" or "hh:mm:ss". So the
>> way I'd parse 34715 is
>>
>> 15 must be minutes, "347" is not valid hours entry. So the error
>> message above the entry box which have the prior entry in it for editing
>> would be:
>>
>> 347 is not a valid hours enter try again. If you having trouble entering
>> a time try using "h:mm:ss.tt am" format.
>
> Hi John,
>
> Although your observations make sense for the US (and probably for the UK), there are countries where other characters are
> supported for separators. For that reason, you will find that we actually try and completely ignore the separator characters in
> our parsing algorithm for dates and times.
>
> As to 110 being 1:10 am, that works fine, but it would never be 1:10 pm. That is one of the reasons why entering times this way
> can be error-prone.
>
> The test list is the current test list after tweaking the libraries. These tests are part of my standard library and use the
> unittest object which is supplied as a library.
>
> Ciao, Neil
>

[Michael]

On 29/01/2013 21:56, kromkowski wrote:
> Yes, 110 would NEVER be 1:10 pm, it would always parse to 1:10 am.
>
> My points are not limited to the US or the UK.
>
> For whatever display format, SIMPOL allows in theory, then you have to
> be able to parse text entered in an allowable format.

My point was that we try to avoid using the text at all, so we can save the trouble. The only format where we have to deal with
the text is when the month is abbreviated or spelled out. All the rest are numbers.

> The first issue is that right now, at least in personal, you can only
> enter text in a format that corresponds to the current display format.
> (Because the modify table does quite work correctly; this is a bug.)

Like I said, this will be resolved in the next release. We fixed a bunch of these recently.

> The second issue is time parsing function in general.
>
> Simpol allows: "hh mm" as a potential display format, therefore the
> parser must be able to parse something entered in that format –
> regardless of what the current display format is. So if I enter, "9 30",
> then the time value for "9:30 am" has to be stored. Not an error telling
> me to reenter or worse no error at all and the leaving of the field blank.
>
> "hhmm" is also an acceptable display format. So if I enter "110", then
> you got to be able to handle that entry and resolve it – in this case
> it must be resolved to the timevalue for "1:10 am"
>
> As to ignoring separators, well I don't see how you do that with
> milliseconds. You can't have milliseconds without a decimal separator.
> And in fact Simpol does not allow you to willy nilly pick a different
> separator for milliseconds. Either it is going to be the dot . Or you'd
> also accept the "," for the decimal in Brazil, Germany, Netherlands,
> Denmark, Italy, Portugal, Romania, Sweden, Slovenia, Greece, Switzerland
> and much of Europe. And for Arabic there is a Arabic Decimal separator
> in Unicode. And for Persian there is Momayyez, which looks a lot like
> the comma or forward slash.
>
> Simpol did not invent this issue. And I'd think there would have
> standardizes way to handle this.
>
> http://en.wikipedia.org/wiki/Date_format_by_country
>
> This has pretty good parsers based on number of digits:
>
> http://www.cpearson.com/excel/DateTimeEntry.htm
>
> Of course, then there is the Thai six hour clock.

As for parsing unusual formats, one of the reasons that we provide the source to these functions is so that if they don't suit
certain requirements, then people can look at them and enhance them (or create their own versions). Obviously, something as
intrinsic as the date and time functions would require them to send the changes to us to be added to the core, so they work at all
levels, but we tend to turn that sort of thing around quickly, as long as the changes won't affect anyone else in a bad way.

We also don't currently correct for the Gregorian Reform for dates before 1753. Superbase does this, but incorrectly calculates
the intervening dates properly instead of improperly – which led to the reform in the first place – which is why in SIMPOL the
date value is 10 days different from the SBL value (SIMPOL also starts at 0 and Superbase starts at 1 – the total difference is 11
days extra in the Superbase values).

Ciao, Neil

[Author]

Posts