Buggy "clock scan" (8.5.0)
ZB
clock scan "41/47/2007" -format "%m/%d/%Y"
1276639200
Could someone verify?
--
ZB
Robert Hicks
That should give you an error for trying an invalid date. I would file
a bug. I get the same on OSX.
Robert
ZB
> That should give you an error for trying an invalid date. I would file
> a bug. I get the same on OSX.
I noticed meanwhile, that it's "carrying over" the "overflow" on the "parent
values" (too much days are adding a month(s), too much months are adding
year/years) - so, writing a "workaround" wasn't that hard - but it still
seems to me for a bug rather, than intended feature(?).
Getting a simple report "invalid date" would be much more useful, I think.
--
ZB
Michael Schlenker
AFAIK its a 'feature', at least Kevin Kenny mentioned something like
that on the Tclers chat some years ago IIRC, because it makes date
arithmetic easier.
Validating might be a seperate issue, maybe some -strict option would be
good.
Michael
Kevin Kenny
>> I noticed meanwhile, that it's "carrying over" the "overflow" on the
>> "parent
>> values" (too much days are adding a month(s), too much months are adding
>> year/years) - so, writing a "workaround" wasn't that hard - but it still
>> seems to me for a bug rather, than intended feature(?).
>>
>> Getting a simple report "invalid date" would be much more useful, I
>> think.
>
> AFAIK its a 'feature', at least Kevin Kenny mentioned something like
> that on the Tclers chat some years ago IIRC, because it makes date
> arithmetic easier.
> Validating might be a seperate issue, maybe some -strict option would be
> good.
It is indeed intended as a feature. In particular, as Michael mentions,
it's useful for doing date/time arithmetic that you can ask for
out-of-range values. (The [clock add] command uses this behaviour
internally, quite a lot.)
I would be willing to entertain a feature request for adding a -strict
option to [clock scan]; there is no such option there presently.
Obviously, it's too late for 8.5.
Incidentally, what validation there was in 8.4 didn't actually work
terribly well. [clock scan] has always accepted quite a lot of rubbish.
--
73 de ke9tv/2, Kevin
Fredderic
Kevin Kenny <ken...@acm.org> wrote:
> Incidentally, what validation there was in 8.4 didn't actually work
> terribly well. [clock scan] has always accepted quite a lot of
> rubbish.
Personally, I find it difficult finding formats that it WILL handle
properly. Most of the time it ends up spitting out some freakish time
that I can't figure out the relevance of. (Like "2a") ;)
I am surprised it doesn't handle day numbers having "th" and friends
appended. I'd have thought that would help unambiguate (err) the date
format. Also I suppose "of" and punctuation are among the rubbish you
mentioned...?
I think if there's any time validation option (which I would love to
see), it'll need to return a list of the parts that were observed, or
perhaps a [clock parse] that returns a dict of what it thinks the parts
of the string are. Maybe some kind of parsing constraint or
direction... Because a time can be "valid", but still very much wrong.
Oh, and just how DO you parse "7/8/9"? It's actually parsed
incorrectly here. the date format for my locale is "%d/%m/%y", which I
think TCL really aught to respect. Such a slim format should never be
used where date portability is needed, which leaves user-entry and
presentation, both of which should match the present locale.
Fredderic
ZB
> Validating might be a seperate issue, maybe some -strict option would be
> good.
Oh, yes: that would be handy.
--
ZB
Robert Hicks
I think it would be good to have a -strict for the clock command. Who
would write the TIP?
Robert
Donal K. Fellows
> Oh, and just how DO you parse "7/8/9"?
Classically, there was always ambiguity between the various orderings
used in that case. Prior to 8.5, you were stuck with using the North
American interpretation (%m/%d/%y) unless you disambiguated things (e.g.
four-digit years[*] and English month abbreviations). With 8.5, you can
say that you're expecting a date in the usual format for a particular
locale. Thus, I can parse that example like this:
% clock scan 7/8/9 -format %x -locale en_GB
1249599600
% clock format 1249599600
Fri Aug 07 00:00:00 BST 2009
Which is actually how *I* would interpret that date. :-)
Donal.
Ilya Zakharevich
ZB
<zbREMOVE_THIS@AND_THISispid.com.pl>], who wrote in article <slrnfns676.5ve...@sarge.my.own.domain.no-net>:
I do not see how it could be implemented. Dates/times are
human-governed entities; subject to local laws etc. E.g.: how you can
determine programmatically how many seconds a particular minute will
have?
How good is a validation routine which gives a probabilistic answer
(even if true 99.99999% of the time)?
Puzzled,
Ilya
ZB
>> > Validating might be a seperate issue, maybe some -strict option would be
>> > good.
>>
>> Oh, yes: that would be handy.
>
> I do not see how it could be implemented.
About the same way, which currently is implemented the recognition of
"overflow". But instead of "carrying it over" on the other time units -
an error will be reported.
--
ZB
Robert Hicks
> [A complimentary Cc of this posting was sent to
> ZB
>
> > Dnia 04.01.2008 Michael Schlenker <schl...@uni-oldenburg.de> napisa³/a:
>
> > > Validating might be a seperate issue, maybe some -strict option would be
> > > good.
>
> > Oh, yes: that would be handy.
>
> I do not see how it could be implemented. Dates/times are
> human-governed entities; subject to local laws etc. E.g.: how you can
> determine programmatically how many seconds a particular minute will
> have?
>
> How good is a validation routine which gives a probabilistic answer
> (even if true 99.99999% of the time)?
>
> Puzzled,
> Ilya
As far as I know it is a worldwide standard that there are 24 hours in
a day, 60 minutes to an hour and 60 seconds to a minute. If there were
a -strict option that would mean not violating any of that. Likewise
there are 12 months and each month has a certain amount of days. If
there were a -strict option you would not be able to violate any of
that.
Those are common assumptions in every programming language that I have
looked at.
Robert
Roy Terry
> Michael Schlenker wrote:
>>> I noticed meanwhile, that it's "carrying over" the "overflow" on the
>>> "parent
>>> values" (too much days are adding a month(s), too much months are adding
>>> year/years) - so, writing a "workaround" wasn't that hard - but it still
>>> seems to me for a bug rather, than intended feature(?).
>>>
>>> Getting a simple report "invalid date" would be much more useful, I
>>> think.
>>
>> AFAIK its a 'feature', at least Kevin Kenny mentioned something like
>> that on the Tclers chat some years ago IIRC, because it makes date
>> arithmetic easier.
>> Validating might be a seperate issue, maybe some -strict option would
>> be good.
>
> It is indeed intended as a feature. In particular, as Michael mentions,
> it's useful for doing date/time arithmetic that you can ask for
> out-of-range values. (The [clock add] command uses this behaviour
> internally, quite a lot.)
>
> I would be willing to entertain a feature request for adding a -strict
> option to [clock scan]; there is no such option there presently.
> Obviously, it's too late for 8.5.
Kevin Kenny
> As far as I know it is a worldwide standard that there are 24 hours in
> a day, 60 minutes to an hour and 60 seconds to a minute. If there were
> a -strict option that would mean not violating any of that. Likewise
> there are 12 months and each month has a certain amount of days. If
> there were a -strict option you would not be able to violate any of
> that.
There *are* actually minutes that have 61 seconds:
http://tf.nist.gov/general/leaps.htm gives an overview.
(And you do *not* want to know the details, I assure you!)
Tcl does not account for leap seconds in this conventional
way because it is indeed more convenient to assume that
every minute has 60 seconds. Instead, it uses a scheme
like http://www.cl.cam.ac.uk/~mgk25/uts.txt to smooth over
the differences by retarding the clock rate by a tiny
fraction.
Considerable controversy now surrounds the practice of
inserting leap seconds:
http://www.ucolick.org/~sla/leapsecs/onlinebib.html
Robert Hicks
> Robert Hicks wrote:
> > As far as I know it is a worldwide standard that there are 24 hours in
> > a day, 60 minutes to an hour and 60 seconds to a minute. If there were
> > a -strict option that would mean not violating any of that. Likewise
> > there are 12 months and each month has a certain amount of days. If
> > there were a -strict option you would not be able to violate any of
> > that.
>
> (And you do *not* want to know the details, I assure you!)
> Tcl does not account for leap seconds in this conventional
> way because it is indeed more convenient to assume that
> every minute has 60 seconds. Instead, it uses a scheme
> the differences by retarding the clock rate by a tiny
> fraction.
>
> Considerable controversy now surrounds the practice of
> inserting leap seconds:http://www.ucolick.org/~sla/leapsecs/onlinebib.html
>
> --
> 73 de ke9tv/2, Kevin
Actually I did know that. : )
tom.rmadilo
> Robert Hicks wrote:
> > As far as I know it is a worldwide standard that there are 24 hours in
> > a day, 60 minutes to an hour and 60 seconds to a minute. If there were
> > a -strict option that would mean not violating any of that. Likewise
> > there are 12 months and each month has a certain amount of days. If
> > there were a -strict option you would not be able to violate any of
> > that.
>
> (And you do *not* want to know the details, I assure you!)
> Tcl does not account for leap seconds in this conventional
> way because it is indeed more convenient to assume that
> every minute has 60 seconds. Instead, it uses a scheme
> the differences by retarding the clock rate by a tiny
> fraction.
>
> Considerable controversy now surrounds the practice of
> inserting leap seconds:http://www.ucolick.org/~sla/leapsecs/onlinebib.html
I think there is some confusion between validating that the data
'could be' a valid date+time and figuring out if the date+time is a
valid moment in time and place.
In general, you can ignore leap seconds unless you are adding an
interval to a date+time. The first (easy) reason is that the
validation procedure would be useless for any future time. You could
also apply this reasoning to anything dealing with timezones. Only the
Z timezone could have any potential future validity.
When doing an interval calculation, leap seconds can usually be
totally ignored. Unless you are adding in seconds around the leap
minute. This is because intervals are added in groups, months to
months, days to days, etc. Because of this, the order of adding
intervals is significant.
Fredderic
"Donal K. Fellows" <donal.k...@manchester.ac.uk> wrote:
> Fredderic wrote:
>> Oh, and just how DO you parse "7/8/9"?
> Classically, there was always ambiguity between the various orderings
> used in that case. Prior to 8.5, you were stuck with using the North
> American interpretation (%m/%d/%y) unless you disambiguated things
> (e.g. four-digit years[*] and English month abbreviations).
Yeah, "dd Mmm yy" is how I generally write dates intended to be
parsed...
Oh, I've got to ask... What's with this:
% clock format [clock scan "2p"]
Fri Jan 11 15:00:00 EST 2008
% clock format [clock scan "2a"]
Fri Jan 11 11:00:00 EST 2008
3pm and 11am... Where on earth does it drag those times from?!? I had
a whole bunch of dates formatted with "a" and "p" instead of "am" and
"pm", and was rather dismayed to find I had to go through them and add
all the "m"s... It was especially frustrating with a web form that
allowed the user to input a date. I let TCL have its best guess at
parsing it, and then if it didn't look like the date that came out the
other end made sense, it prompted them with a date entry page that had
a calendar, and no where for the user to actually type a single
character. ;)
> With 8.5, you can say that you're expecting a date in the usual
> format for a particular locale. Thus, I can parse that example like
> this: % clock scan 7/8/9 -format %x -locale en_GB
> 1249599600
> % clock format 1249599600
> Fri Aug 07 00:00:00 BST 2009
> Which is actually how *I* would interpret that date. :-)
Definitely a positive thing... But it's a shame -locale (or even
better, the current system locale) doesn't apply to the default
guess-the-format parsing mode, as the day/month tie-breaker.
Date parsing is definitely an arcane art... I break into a sweat every
time I'm asked to parse a user-supplied date. It's one of those hard
to do well things, that is so easy to do very very badly. Perhaps a
[clock guessdate "user-supplied-date"] command would work, that
puts some emphasis on trying to figure out if it really does have a
date. ;)
Fredderic
ZB
> Yeah, "dd Mmm yy" is how I generally write dates intended to be
> parsed...
...and wouldn't be better just "YYYYmmdd"? It's universal, and no confusion
there.
--
ZB
Fredderic
ZB <zbREMOVE_THIS@AND_THISispid.com.pl> wrote:
For date-stamped file names, sure, it's a great format, especially with
its natural sortability. But it's not particularly obvious, or easy to
read. The "dd Mmm yy" format, on the other hand, is immediately
identifiable as a date ("Mmm" of course, being the three letter month
abbreviation), still reasonably compact, and parses just fine. And yes,
you can use a four-digit year to make sure there's absolutely no
confusion.
In any case, that was just a curiosity point. My real interest was
related more to dates of an uncertain format, where [clock scan] is
required to make a "best guess". In such cases, using present (or
specified) locale as a tie-breaker would be a good thing, in my opinion.
Fredderic
Ilya Zakharevich
ZB
> Dnia 05.01.2008 Ilya Zakharevich <nospam...@ilyaz.org> napisał/a:
>
> >> > Validating might be a seperate issue, maybe some -strict option would be
> >> > good.
> > I do not see how it could be implemented.
> About the same way, which currently is implemented the recognition of
> "overflow". But instead of "carrying it over" on the other time units -
> an error will be reported.
Same difference. The fact of whether it is an overflow or not does
depend on the laws accepted at a particular year in a particular
country (or state/province, or a county, or a municipality).
Yours,
Ilya
Ilya Zakharevich
<tom.r...@gmail.com>], who wrote in article <0f023a29-43cd-4059...@x69g2000hsx.googlegroups.com>:
> In general, you can ignore leap seconds unless you are adding an
> interval to a date+time. The first (easy) reason is that the
> validation procedure would be useless for any future time. You could
> also apply this reasoning to anything dealing with timezones. Only the
> Z timezone could have any potential future validity.
There are 2 manageable situations: when there is no validation
procedure, and when there is a reliable validation procedure.
IMO, the situation of having an unreliable validation procedure is of
negative impact: people who know that it is unreliable will not use
it, and the people who do not know it is unreliable will rely on it.
[And I do not consider it as a solution if one has a fine print in
documenation which gives a long list of situation where one
can/cannot rely on the validator.]
Yours,
Ilya