Prev: tcl, tclreadline and expect issue
Next: Tk [photo]: when does a dithering process occur ?
From: Bruce on 30 Jul 2010 10:38

>> FREE FORM SCAN
>> If the clock scan command is invoked without a -format option, then it
>> requests a free-form scan. This form of scan is deprecated. The reason
>> for the deprecation is that there are too many ambiguities. (Does the
>> string �2000� represent a year, a time of day, or a quantity?) No set of
>> rules for interpreting free-form dates and times has been found to give
>> unsurprising results in all cases.
>>
>> so - don't use deprecated features if you want consistency
>>
>> use the -format option and specify a consistent time base
>>
>> bruce
>
> I can accept that a format is needed when using "2000" or similar
> string but what format can I specify for the word "today" that will
> make it more clear? and if "today" is not clear then what about
> "yesterday" and "tomorrow"? for me it seems inconsistent and something
> that should change even in the price of backward compatibility as you
> can always change "today" to "now" to keep they way you used to do it.

i agree it is inconsistent and surprising.

My point was more to the fact that you can avoid it. Anytime you have
code guessing what you meant you can be bitten if it guesses wrong.
(Still waiting on TIP 131) - and by being a bit more specific you can
avoid the pitfall

- if you want midnight in all cases then do

clock format [clock scan "00:00:00 yesterday"]
clock format [clock scan "00:00:00 today"]
clock format [clock scan "00:00:00 tomorrow"]

Bruce

From: Simon on 30 Jul 2010 11:50
On 30/07/2010 04:09, yahalom wrote:
> On Jul 30, 12:43 am, Bruce<Bruce_do_not_...(a)example.com> wrote:
>> yahalom wrote:
>>> I see no difference between "clock scan now" and "clock scan today"
>>> also today is inconsistent with other relative dates
>>
>>> doing:
>>> %clock format [clock scan yesterday]
>>
>>> %Mon Jul 19 00:00:00 IDT 2010
>>
>>> %clock format [clock scan tomorrow]
>>
>>> Wed Jul 21 00:00:00 IDT 2010
>>
>>> %clock format [clock scan today]
>>
>>> %Tue Jul 20 14:41:13 IDT 2010
>>
>>> which is same as
>>
>>> %clock format [clock scan now]
>>
>>> I would expect:
>>> %clock format [clock scan today]
>>
>>> %Tue Jul 20 00:00:00 IDT 2010
>>
>>> is this a bug?
>>
>> to quote from the clock manual page:
>>
>> FREE FORM SCAN
>> If the clock scan command is invoked without a -format option, then it
>> requests a free-form scan. This form of scan is deprecated. The reason
>> for the deprecation is that there are too many ambiguities. (Does the
>> string �2000� represent a year, a time of day, or a quantity?) No set of
>> rules for interpreting free-form dates and times has been found to give
>> unsurprising results in all cases.
>>
>> so - don't use deprecated features if you want consistency
>>
>> use the -format option and specify a consistent time base
>>
>> bruce
>
> I can accept that a format is needed when using "2000" or similar
> string but what format can I specify for the word "today" that will
> make it more clear? and if "today" is not clear then what about
> "yesterday" and "tomorrow"? for me it seems inconsistent and something
> that should change even in the price of backward compatibility as you
> can always change "today" to "now" to keep they way you used to do it.

Inconsistent yes, suprising no. Interpreting "today" as "now" rather
than "the beginning of today" seems perfectly reasonable to me even if
it's not what everyone expects. Clearly it isn't a bug and the idea of
changing it thereby causing some existing scripts to break is absurd.

Simon

From: Robert Heller on 30 Jul 2010 13:39
At Fri, 30 Jul 2010 16:50:52 +0100 Simon <simon(a)whiteowl.co.uk> wrote:

>
> On 30/07/2010 04:09, yahalom wrote:
> > On Jul 30, 12:43 am, Bruce<Bruce_do_not_...(a)example.com> wrote:
> >> yahalom wrote:
> >>> I see no difference between "clock scan now" and "clock scan today"
> >>> also today is inconsistent with other relative dates
> >>
> >>> doing:
> >>> %clock format [clock scan yesterday]
> >>
> >>> %Mon Jul 19 00:00:00 IDT 2010
> >>
> >>> %clock format [clock scan tomorrow]
> >>
> >>> Wed Jul 21 00:00:00 IDT 2010
> >>
> >>> %clock format [clock scan today]
> >>
> >>> %Tue Jul 20 14:41:13 IDT 2010
> >>
> >>> which is same as
> >>
> >>> %clock format [clock scan now]
> >>
> >>> I would expect:
> >>> %clock format [clock scan today]
> >>
> >>> %Tue Jul 20 00:00:00 IDT 2010
> >>
> >>> is this a bug?
> >>
> >> to quote from the clock manual page:
> >>
> >> FREE FORM SCAN
> >> If the clock scan command is invoked without a -format option, then it
> >> requests a free-form scan. This form of scan is deprecated. The reason
> >> for the deprecation is that there are too many ambiguities. (Does the
> >> string Â"2000Â" represent a year, a time of day, or a quantity?) No set of
> >> rules for interpreting free-form dates and times has been found to give
> >> unsurprising results in all cases.
> >>
> >> so - don't use deprecated features if you want consistency
> >>
> >> use the -format option and specify a consistent time base
> >>
> >> bruce
> >
> > I can accept that a format is needed when using "2000" or similar
> > string but what format can I specify for the word "today" that will
> > make it more clear? and if "today" is not clear then what about
> > "yesterday" and "tomorrow"? for me it seems inconsistent and something
> > that should change even in the price of backward compatibility as you
> > can always change "today" to "now" to keep they way you used to do it.
>
> Inconsistent yes, suprising no. Interpreting "today" as "now" rather
> than "the beginning of today" seems perfectly reasonable to me even if
> it's not what everyone expects. Clearly it isn't a bug and the idea of
> changing it thereby causing some existing scripts to break is absurd.
>
> Simon

And as was noted in another reply, 'yesterday', 'tomorrow', and 'today'
are really not 'absolute' times anyway -- they all are qualifiers,
generally meant to qualify a partitular time (eg yesterday at noon:
'12:00 yesterday', tomorrow at midnight: '00:00 tomorrow', today at
suppertime: '17:00 today', etc.) and not really meant to use all by
themselves. 'now' is always an absolute time -- there is only one now!

>
>
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
heller(a)deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/

From: Craig on 30 Jul 2010 14:02
On 7/30/2010 10:39 AM, Robert Heller wrote:
> And as was noted in another reply, 'yesterday', 'tomorrow', and 'today'
> are really not 'absolute' times anyway -- they all are qualifiers,
> generally meant to qualify a partitular time (eg yesterday at noon:
> '12:00 yesterday', tomorrow at midnight: '00:00 tomorrow', today at
> suppertime: '17:00 today', etc.) and not really meant to use all by
> themselves. 'now' is always an absolute time -- there is only one now!

I'm going with the crowd that thinks the current behavior is inconsistent:
% puts "[clock scan today] - [clock scan today] - [clock scan yesterday] -
[clock scan tomorrow]"
1280512856 - 1280512856 - 1280386800 - 1280559600

if today is relative to the current time, then yesterday and tomorrow s.b.
relative to the current time or conversely, if yesterday and tomorrow are
relative to midnight today, then today should be relative to midnight today.

craig
From: Robert Heller on 30 Jul 2010 15:19
At Fri, 30 Jul 2010 11:02:02 -0700 Craig <ask-me(a)somewhere.net> wrote:

>
> On 7/30/2010 10:39 AM, Robert Heller wrote:
> > And as was noted in another reply, 'yesterday', 'tomorrow', and 'today'
> > are really not 'absolute' times anyway -- they all are qualifiers,
> > generally meant to qualify a partitular time (eg yesterday at noon:
> > '12:00 yesterday', tomorrow at midnight: '00:00 tomorrow', today at
> > suppertime: '17:00 today', etc.) and not really meant to use all by
> > themselves. 'now' is always an absolute time -- there is only one now!
>
> I'm going with the crowd that thinks the current behavior is inconsistent:
> % puts "[clock scan today] - [clock scan today] - [clock scan yesterday] -
> [clock scan tomorrow]"
> 1280512856 - 1280512856 - 1280386800 - 1280559600
>
> if today is relative to the current time, then yesterday and tomorrow s.b.
> relative to the current time or conversely, if yesterday and tomorrow are
> relative to midnight today, then today should be relative to midnight today.

The problem is that all three are not really meaningful *without* a
specified time. That is 'today', 'yesterday', and 'tomorrow' are
abiguous and there is no reason to expect consistent results when they
are used without a time. 'It is not a bug, it is a feature.'

>
> craig
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
heller(a)deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: tcl, tclreadline and expect issue
Next: Tk [photo]: when does a dithering process occur ?