Masochist seeking same for beta-testing fun

[Charles Dye]

Are you brave? Adventurous? Are your backups completely up-to-date? Have you been waiting for the chance to run untested newbie code on your very own computer? Then I have an opportunity for you!

I'm posting a beta build of a date-picker plugin, and would appreciate substantive feedback from anyone foolish enough to test it. Most especially, please beat on the calendar and report any incorrect results.

unm.edu/~cdye/dl/pickdate.zip

The random file-deletion code is probably disabled, but no promises. The quickest way to reach me is through this forum.

 

[dcantor]

Are you brave? Adventurous? Are your backups completely up-to-date? Have you been waiting for the chance to run untested newbie code on your very own computer? Then I have an opportunity for you!
...

I downloaded it and read the documentation. I'll experiment with it a little later. It looks like something I can use.

A couple of observations based on the documentation:

1. Why two separate bits in the flags argument for Sunday on left and Sunday on right? What if someone selects both? Or neither? How about instead reserve 3 bits for day number to appear in left-most column, 0=Sunday, 1=Monday, ... 6=Saturday, 7=Error ?

2. Date formats: format 1 and 2 are like the TCC formats of the same number except with 4-digit year instead of 2-digit year. How about a way to choose 2- or 4-digit years? (I would personally always choose 4-digits unless 2 digits were required for whatever I'm going to feed the date to.)

I'm sure I'll have more questions later.

Thanks for posting this.

 

[Charles Dye]

1. Why two separate bits in the flags argument for Sunday on left and Sunday on right? What if someone selects both? Or neither? How about instead reserve 3 bits for day number to appear in left-most column, 0=Sunday, 1=Monday, ... 6=Saturday, 7=Error ?

Two bits because there are three possibilities: force Sundays on the left, force Sundays on the right, or use the local default. Both bits set is currently undefined, and acts the same as both clear: local default.

The idea of putting Tuesdays, Wednesdays, etc. in the first column makes my cerebellum hurt. Does anyone actually do that?

2. Date formats: format 1 and 2 are like the TCC formats of the same number except with 4-digit year instead of 2-digit year. How about a way to choose 2- or 4-digit years? (I would personally always choose 4-digits unless 2 digits were required for whatever I'm going to feed the date to.)

Wouldn't be difficult to do, either by defining additional date formats or by adding a bit to flags. Does anyone have a need for two-digit years?

 

[dcantor]

Bug, I think.

The date format is certainly used for formatting the output, but appears to be ignored for input. The input date, if specified as an absolute date, appears to be interpreted as format 2 unless it begins with a 4-digit year.

Here's a demonstration. Wherever there wasn't an error, I selected the "OK" button. My system default is format 1, as shown.

C:\work> echo %_date
03-17-09

C:\work> echo %@pickdate[,3-17-09]
PickDate: Invalid date "3-17-09"

C:\work> echo %@pickdate[,17-3-09]
17-03-2009

C:\work> echo %@pickdate[,17-3-09,1]
03-17-2009

C:\work> echo %@pickdate[,17-3-09,2]
17-03-2009

C:\work> echo %@pickdate[,17-3-09,3]
2009-03-17

 

[dcantor]

Two bits because there are three possibilities: force Sundays on the left, force Sundays on the right, or use the local default. Both bits set is currently undefined, and acts the same as both clear: local default.

The idea of putting Tuesdays, Wednesdays, etc. in the first column makes my cerebellum hurt. Does anyone actually do that?

Well, in a past life, I worked in a place whose business week began on Friday! And another place whose PAYROLL week ended on Friday (so Saturday was the start of the payroll week).

But I kind of agree with your feeling. It made my head hurt. Yet I felt I had to ask (even though I don't have a current use for such a thing).


As for 2-digit years, fortunately TCC's date functions seem to accept 4-digit years everywhere, but I still think it would be a good option (and I wish there were a way to force TCC's date functions to return 4-digit years for formats 1 and 2.


So, one more suggestion: Another parameter for a timeout (in seconds) after which the currently selected date is returned. The parameter could be zero for immediate return, but with a default of, oh, I don't know, 86400, perhaps.

 

[Charles Dye]

Bug, I think.

The date format is certainly used for formatting the output, but appears to be ignored for input. The input date, if specified as an absolute date, appears to be interpreted as format 2 unless it begins with a 4-digit year.

Two bugs, I think. The failure to use the user-specified format to interpret input dates is an obvious and trivial bug. Where it's getting that incorrect format 2 is a mystery to me.

I'm putting up an updated .ZIP which should fix bug #1, and takes a wild stab at #2. Let me know.

 

[dcantor]

Two bugs, I think. The failure to use the user-specified format to interpret input dates is an obvious and trivial bug. Where it's getting that incorrect format 2 is a mystery to me.

I'm putting up an updated .ZIP which should fix bug #1, and takes a wild stab at #2. Let me know.

Yup. 3-1-09 yields 03-01-2009 for both formats 1 and 2 (that's correct).
For formats 3 and 4, the output is 2003-01-09. The correct months showed up in the selection window: Format 1 -- March 2009, format 2 -- January 2009, formats 3 & 4 -- January 2003.

BUT: with no format specified, the input is interpreted as format 2, even though my default format is format 1.

 

[Steve Fabian]

dcantor wrote:
| ---Quote (Originally by Charles Dye)---
| Two bits because there are three possibilities: force Sundays on the
| left, force Sundays on the right, or use the local default. Both
| bits set is currently undefined, and acts the same as both clear:
| local default.
|
| The idea of putting Tuesdays, Wednesdays, etc. in the first column
| makes my cerebellum hurt. Does anyone actually do that? ---End
| Quote---
| Well, in a past life, I worked in a place whose business week began
| on Friday! And another place whose PAYROLL week ended on Friday (so
| Saturday was the start of the payroll week).
|
| But I kind of agree with your feeling. It made my head hurt. Yet I
| felt I had to ask (even though I don't have a current use for such a
| thing).


Payroll weeks running Sat. to Fri. make sense, esp. in states where
employees must be paid within 7 days. Two of the grocery store chains where
I shop have their "specials" week running from Wednesday through Tuesday,
probably for restocking reasons.

AFAIK the moslem calendar's holy day of the week is Friday, though I don't
know whether it is considered to be the first or the last day of the week.

A calendar display based on these business or religious cycles would
certainly be convenient for some. However, it being actually trivial to
implement it, I'd go for that 3-bit "start of display week" code.

What is "local default"?
--
Steve

 

[Charles Dye]

Yup. 3-1-09 yields 03-01-2009 for both formats 1 and 2 (that's correct).
For formats 3 and 4, the output is 2003-01-09. The correct months showed up in the selection window: Format 1 -- March 2009, format 2 -- January 2009, formats 3 & 4 -- January 2003.

That's right, then.

BUT: with no format specified, the input is interpreted as format 2, even though my default format is format 1.

That's definitely wrong. Curious. I'm calling GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_ILDATE ....) and it seems to be returning a string value of "1", meaning d/m/y format. It should be possible to verify that from TCC using %@WINAPI, but I haven't figured out the magic incantation yet.

 

[Charles Dye]

AFAIK the moslem calendar's holy day of the week is Friday, though I don't know whether it is considered to be the first or the last day of the week.

I'm not sure that's really relevant, as the Islamic calendar is completely different from the Gregorian....

What is "local default"?

I'm using GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_IFIRSTDAYOFWEEK ...) and checking whether the return value is zero or otherwise.

 

[dcantor]

That's right, then.



That's definitely wrong. Curious. I'm calling GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_ILDATE ....) and it seems to be returning a string value of "1", meaning d/m/y format. It should be possible to verify that from TCC using %@WINAPI, but I haven't figured out the magic incantation yet.

> echo %@regquery["HKEY_CURRENT_USER\Control Panel\International\iDate"]

0

(There's a single space between Control and Panel.)

Or, in TCC:

set dateformat=%@day[2-1-3]
if %@len[%@year[%_date]] eq 4 set dateformat=4

 

[Steve Fabian]

Charles Dye wrote:
| I'm using GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_IFIRSTDAYOFWEEK
| ...) and checking whether the return value is zero or otherwise.

How is that value set? I just checked my WinXP SP3's "regional settings" and
could not find a method to affect it (possibly changing the country where I
am located would do it).

I have an enhanced clock on my taskbar: TClockEx which allows choosing any day
of the week for leftmost column.
--
Steve

 

[dcantor]

Charles Dye wrote:
| I'm using GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_IFIRSTDAYOFWEEK
| ...) and checking whether the return value is zero or otherwise.

How is that value set? I just checked my WinXP SP3's "regional settings" and
could not find a method to affect it (possibly changing the country where I
am located would do it).

I believe it's set as a by-product of choosing the locale in Control Panel \ Regional Settings.

I have an enhanced clock on my taskbar: TClockEx which allows choosing any day
of the week for leftmost column.

I use that application, too.

 

[Charles Dye]

BUT: with no format specified, the input is interpreted as format 2, even though my default format is format 1.

Dave, would you mind running a test .EXE and relaying the results? I'd really like to understand what's going on here.

unm.edu/~cdye/dl/localetest.zip

 

[Steve Fabian]

dcantor wrote:
| ---Quote (Originally by Steve Fábián)---
| Charles Dye wrote:
|| I'm using GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_IFIRSTDAYOFWEEK
|| ...) and checking whether the return value is zero or otherwise.
|
| How is that value set? I just checked my WinXP SP3's "regional
| settings" and
| could not find a method to affect it (possibly changing the country
| where I
| am located would do it).
| ---End Quote---
| I believe it's set as a by-product of choosing the locale in Control
| Panel \ Regional Settings.

That seems inadequate in a worldwide economy. It may work perfectly for
local information, but anyone involved in international activities may need
access to the customary formats of more than one country. Charles, that's
why the TClockEx feature of selecting any day of the week to be the leftmost
ought to be in your code.
--
Steve

 

[Charles Dye]

That seems inadequate in a worldwide economy. It may work perfectly for local information, but anyone involved in international activities may need access to the customary formats of more than one country. Charles, that's why the TClockEx feature of selecting any day of the week to be the leftmost ought to be in your code.

All right, all right.... First priority is finding and fixing problems, Dave's little-endian date format first among them. But I'll add some way to put any day on the left before v1.00. The lowest two bits of flags will be undefined in the next build.

 

[Charles Dye]

Dave, would you mind running a test .EXE and relaying the results? I'd really like to understand what's going on here.

unm.edu/~cdye/dl/localetest.zip

Dave? Are you still around?

 

[dcantor]

Dave? Are you still around?

Charles, I was out and about today. I just got back.

If you have something for me to try, I can do so.

 

[dcantor]

Dave? Are you still around?

Okay, I downloaded version 0.94.

The previous bugs are fixed. Thank you. The default date format now appears to be the system default.

But now, I've noticed an inconsistency:

From the help file: [FONT=Courier New, monospace]format[/FONT]: the date format used to return the selected date. Also used to interpret input dates if the format is ambiguous (does not begin with a four-digit year.)




I tried echo %@pickdate[,09-W5-1,5]
Bzzt. Error.



If OUTPUT is desired in format 5, then INPUT is read only in the system default (I presume). I hate to ask for more, but it would be really better, I think, if the input and output formats were separately specified. The default for input format should be the system setting, the default for OUTPUT format should be the input format.

I haven't tried start date and end date. Does the format for those follow the format for the input format?

I don't mean to throw rocks. This function is already quite useful just the way it is. Thanks for doing this, Charles.

 

[Charles Dye]

Okay, I downloaded version 0.94.

The previous bugs are fixed. Thank you. The default date format now appears to be the system default.

I was hoping to get some further info from you to help fix it, but if it works now, then perhaps I've guessed correctly....

But now, I've noticed an inconsistency:

From the help file: [FONT=Courier New, monospace]format[/FONT]: the date format used to return the selected date. Also used to interpret input dates if the format is ambiguous (does not begin with a four-digit year.)

I tried echo %@pickdate[,09-W5-1,5]
Bzzt. Error.

The doc says that input dates can be in ISO format with a four-digit year; I suppose it really should say in any of the ISO formats, with a four-digit year. You can do that; you just need a 2009 instead of an 09 for it to be correctly recognized.

I haven't tried start date and end date. Does the format for those follow the format for the input format?

Yes, it's one parser for all three dates.

 

[Charles Dye]

I'm posting an updated beta build of PickDate:

unm.edu/~cdye/dl/pickdate.zip

This one has additional tweaks to the date parser, support for outputting two-digit years, and an option put any day of the week in the leftmost column.

 

[dcantor]

I was hoping to get some further info from you to help fix it, but if it works now, then perhaps I've guessed correctly....

I'm happy to give you more feedback. What can I tell you?

The doc says that input dates can be in ISO format with a four-digit year; I suppose it really should say in any of the ISO formats, with a four-digit year. You can do that; you just need a 2009 instead of an 09 for it to be correctly recognized.

Yes, it's one parser for all three dates.

Yes, but the doc also says that the date-format argument is (also) used to interpret the input date when it is ambiguous, and anything with a W in the second number, and anything with just two numbers is not ambiguous. I'm happy with the restriction; I'm just indicating that the behavior doesn't match the doc. It would be better to recognize a date like 03-W5-01 as being equivalent to 2003-W05-1 and 1-2 as equivalent to 2001-002, but if not, please clarify it in the doc.

 

[Charles Dye]

I'm happy to give you more feedback. What can I tell you?

If you wouldn't mind downloading and running a test program, it would confirm (or refute) my understanding that LOCALE_ILDATE and LOCALE_IDATE give different values on your system. The tester is here:

unm.edu/~cdye/dl/localetest.zip

Yes, but the doc also says that the date-format argument is (also) used to interpret the input date when it is ambiguous, and anything with a W in the second number, and anything with just two numbers is not ambiguous. I'm happy with the restriction; I'm just indicating that the behavior doesn't match the doc. It would be better to recognize a date like 03-W5-01 as being equivalent to 2003-W05-1 and 1-2 as equivalent to 2001-002, but if not, please clarify it in the doc.

It's my understanding that ISO 8601 requires four-digit years, so I figure that anything starting with a number below 1753 is not genuinely ISO. In the case of a date where the second part begins with a W, I could assume it's intended as an ISO week date and assign a century myself (though I don't think that would comply with the spec?) But in a case like 1-2, I think it's more likely to mean January 2 (or February 1?) of some year. So I'm going to continue to require full, four-digit years for all of the ISO formats....

 

[dcantor]

If you wouldn't mind downloading and running a test program, it would confirm (or refute) my understanding that LOCALE_ILDATE and LOCALE_IDATE give different values on your system. The tester is here:

unm.edu/~cdye/dl/localetest.zip

Here's the result:

C:\temp> localetest

GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_ILDATE ....) returns "1".
GetLocaleInfo(LOCALE_SYSTEM_DEFAULT, LOCALE_ILDATE ....) returns "1".

GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_IDATE ....) returns "0".
GetLocaleInfo(LOCALE_SYSTEM_DEFAULT, LOCALE_IDATE ....) returns "0".

GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SDATE ....) returns "-".
GetLocaleInfo(LOCALE_SYSTEM_DEFAULT, LOCALE_SDATE ....) returns "-".

GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_IFIRSTDAYOFWEEK ....) returns "6".
GetLocaleInfo(LOCALE_SYSTEM_DEFAULT, LOCALE_IFIRSTDAYOFWEEK ....) returns "6".

It's my understanding that ISO 8601 requires four-digit years, so I figure that anything starting with a number below 1753 is not genuinely ISO. In the case of a date where the second part begins with a W, I could assume it's intended as an ISO week date and assign a century myself (though I don't think that would comply with the spec?) But in a case like 1-2, I think it's more likely to mean January 2 (or February 1?) of some year. So I'm going to continue to require full, four-digit years for all of the ISO formats....[/quote]

That's a totally reasonable. I'm only asking that it be documented.

 

[Charles Dye]

Here's the result:

Thank you for all your help. It looks like IDATE is the way to go. Wish I understood the difference between the two of them....

That's a totally reasonable. I'm only asking that it be documented.

Will do, in the next build.