Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Why I am getting wrong results from clock scan?

80 views
Skip to first unread message

Georgios Petasis

unread,
Nov 16, 2017, 12:42:19 PM11/16/17
to
Hi all,

I am trying to understand what clock scan does, and why it cannot parse
a year. In the man page, there is an example:

clock format [clock scan {2004-10-30 05:00:00} -format {%Y-%m-%d %H:%M:%S}]

It works. Dropping hour:

clock format [clock scan {2004-10-30} -format {%Y-%m-%d}]

Dropping the day, it does not work:

clock format [clock scan {2004-10} -format {%Y-%m}]

It returns a date in the current year. Why?

George

walto...@gmail.com

unread,
Nov 16, 2017, 4:30:32 PM11/16/17
to
On Thursday, November 16, 2017 at 11:42:19 AM UTC-6, Georgios Petasis wrote:
> clock format [clock scan {2004-10} -format {%Y-%m}]

It returns the first hour/min/sec (midnight) when the time is dropped, so it seems like the logical thing for it to do when the day is dropped is use the first day of the month.

Gerald Lester

unread,
Nov 16, 2017, 5:19:52 PM11/16/17
to
Rule #7 on the SCANNING TIMES section of the [clock] man page.

--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+----------------------------------------------------------------------+

sled...@gmail.com

unread,
Nov 16, 2017, 6:09:15 PM11/16/17
to
Amen...or, as in the new beer commercial, Hey dilly dilly...

Georgios Petasis

unread,
Nov 17, 2017, 3:48:09 AM11/17/17
to
Στις 17/11/2017 00:19, ο Gerald Lester έγραψε:
> On 11/16/2017 03:30 PM, walto...@gmail.com wrote:
>> On Thursday, November 16, 2017 at 11:42:19 AM UTC-6, Georgios Petasis
>> wrote:
>>> clock format [clock scan {2004-10} -format {%Y-%m}]
>>
>> It returns the first hour/min/sec (midnight) when the time is dropped,
>> so it seems like the logical thing for it to do when the day is
>> dropped is use the first day of the month.
>>
>
> Rule #7 on the SCANNING TIMES section of the [clock] man page.
>

I cannot understand :-)
I have given a year, so this is a perfectly and complete defined date.
2004 is a perfectly defined date by iso 8601.
So, if giving 2004 you are getting back 2017 instead of 2004, and this
is justified by the rules, then the rules are seriously flawed.

George

Andreas Leitgeb

unread,
Nov 17, 2017, 4:09:41 AM11/17/17
to
Georgios Petasis <peta...@yahoo.gr> wrote:
> Στις 17/11/2017 00:19, ο Gerald Lester έγραψε:
>> On 11/16/2017 03:30 PM, walto...@gmail.com wrote:
>>> On Thursday, November 16, 2017 at 11:42:19 AM UTC-6, Georgios Petasis
>>> wrote:
>>>> clock format [clock scan {2004-10} -format {%Y-%m}]
>>> It returns the first hour/min/sec (midnight) when the time is dropped,
>>> so it seems like the logical thing for it to do when the day is
>>> dropped is use the first day of the month.
>> Rule #7 on the SCANNING TIMES section of the [clock] man page.
> I have given a year, so this is a perfectly and complete defined date.
> 2004 is a perfectly defined date by iso 8601.

Note the notion of "complete set" in [3]. It's not just about the year.

> So, if giving 2004 you are getting back 2017 instead of 2004, and this
> is justified by the rules, then the rules are seriously flawed.

Without such a complete set, there are just too many ambiguities to get sane
semantics. It could be feasible to define some "partial" sets that might
also be used to define a date (with defined defaults for the remaining fields),
but clock scan is already complex enough, έτσι δεν είναι;

Rich

unread,
Nov 17, 2017, 8:21:08 AM11/17/17
to
Georgios Petasis <peta...@yahoo.gr> wrote:
> ???? 17/11/2017 00:19, ? Gerald Lester ??????:
If you know you have year and month (which seems the case from your
example) you can work around the clock scan rules by supplying an
artificial day as part of the clock scan call itself. That will give
the "complete set" that another poster mentioned and return a value
(the example below uses first day of month) within the year and month
of your input.:

$ rlwrap tclsh
% set val 2004-10
2004-10

# original, without artificial day
% clock format [clock scan $val -format %Y-%m]
Fri Nov 17 00:00:00 EST 2017

# add artificial day
% clock format [clock scan $val-01 -format %Y-%m-%d]
Fri Oct 01 00:00:00 EDT 2004

Georgios Petasis

unread,
Nov 17, 2017, 10:21:33 AM11/17/17
to
Στις 17/11/2017 11:09, ο Andreas Leitgeb έγραψε:
> Georgios Petasis <peta...@yahoo.gr> wrote:
>> Στις 17/11/2017 00:19, ο Gerald Lester έγραψε:
>>> On 11/16/2017 03:30 PM, walto...@gmail.com wrote:
>>>> On Thursday, November 16, 2017 at 11:42:19 AM UTC-6, Georgios Petasis
>>>> wrote:
>>>>> clock format [clock scan {2004-10} -format {%Y-%m}]
>>>> It returns the first hour/min/sec (midnight) when the time is dropped,
>>>> so it seems like the logical thing for it to do when the day is
>>>> dropped is use the first day of the month.
>>> Rule #7 on the SCANNING TIMES section of the [clock] man page.
>> I have given a year, so this is a perfectly and complete defined date.
>> 2004 is a perfectly defined date by iso 8601.
>
> Note the notion of "complete set" in [3]. It's not just about the year.

Yes I saw this. But anybody would expect that only a year is a complete set.

>
>> So, if giving 2004 you are getting back 2017 instead of 2004, and this
>> is justified by the rules, then the rules are seriously flawed.
>
> Without such a complete set, there are just too many ambiguities to get sane
> semantics. It could be feasible to define some "partial" sets that might
> also be used to define a date (with defined defaults for the remaining fields),
> but clock scan is already complex enough, έτσι δεν είναι;
>

I think these are resolved issues. iso 8601 defines a year. 2004Z is
2004-01-01T00:00:00Z.

No one expects to give 2004 and get back 2017...

George

Georgios Petasis

unread,
Nov 17, 2017, 10:45:13 AM11/17/17
to
It is funny that a random converter on the net works as expected:

https://coderstoolbox.net/unixtimestamp/

You put "2004" in the ISO 8601 time filed, and you get "Thu, 1 Jan 2004
00:00:00 +02:00"

And you use clock scan, and you get 2017 :D :D :D
(Well, mostly funny after you debug what is causing the error).

George

Eric

unread,
Nov 18, 2017, 8:10:06 AM11/18/17
to
clock scan returns a "Unix time", and without a date it is not possible
to get the time right, and 00:00:00 can end up in the previous
year/month.

However:

% package require clock::iso8601 ; # from Tcllib
% clock format [clock::iso8601 parse_date {2004-10}]
Fri Oct 01 00:00:00 CEST 2004
% clock format [clock::iso8601 parse_date {2004}]
Thu Jan 01 00:00:00 CET 2004
%
>
> No one expects to give 2004 and get back 2017...

% clock format [clock::iso8601 parse_date 1480-09]
Fri Sep 01 00:00:00 LMT 1480


Eric
--
ms fnd in a lbry

Georgios Petasis

unread,
Nov 18, 2017, 8:22:11 AM11/18/17
to
Dear Eric,

I know about the iso8601 package, and its bugs. Try adding a Z for
example :-)
But this is a whole other story, it is a package. clock is a core
command, it shouldn't misbehave.

George
0 new messages