POLL: New 'clock scan' formats 
Author Message
 POLL: New 'clock scan' formats

I was pointed to a good doc on ISO time formats:
        http://www.*-*-*.com/ ~mgk25/iso-time.html

I would like people who find that 'clock scan' does not support enough
standard formats to visit this page, and whatever other ref they have
(like maybe SQL DB time formats), and then tell me what specific formats
are important to you.

We will be adding some new scan formats to the clock command, but if
you delve into each that is discussed in the above link, you will find
some sticky ambiguities that we'd rather avoid (especially anything
that might change a currently valid scan format - we won't do that).

You can mail me direct if it's a simple format request, or post it
here if you feel there is some ambiguity.  Make sure to check against
the currently valid clock scan formats.

--
   Jeffrey Hobbs                          The Tcl Guy
   jeffrey.hobbs at scriptics.com         Scriptics Corp.



Fri, 12 Apr 2002 03:00:00 GMT  
 POLL: New 'clock scan' formats
Hi,

This isn't really what you asked for: New time formats, that should be
scannable, but it certainly is related:

The clock command doesn't handle time *differences* right now. E.g.
formatting 123 seconds to be "00:02:03" and vice-versa. It is very
usefull for things like "time elapsed" etc.

Peter



Fri, 12 Apr 2002 03:00:00 GMT  
 POLL: New 'clock scan' formats


Quote:
> I would like people who find that 'clock scan' does not support enough
> standard formats to visit this page, and whatever other ref they have
> (like maybe SQL DB time formats), and then tell me what specific
formats
> are important to you.

Joy!

As far as the ISO 8601 spec goes, the really essential ones
(from my perspective) are:

%Y-%m-%d %H:%M:%S
and
%Y%m%d %H:%M:%S

and the various truncations of such.  Java JDBC Timestamp's
are the first format with the dashes, something TclX and Tcl
have long choked on.

Another one is the nice, localizable

%e-%b-%Y %H:%M:%S

Which again fails for the minus-signs.

Being able to parse localized months for %b would be really
nice.  The whole purpose of my [clock getdate] extension that
interfaces to SVR4 (Solaris') getdate() is to overcome this.

Adding a -format to clock scan would be a nice addition and
could be used to validate a date/time string against a strict
spec.  Adding a -formats [list FMT1 FMT2 FMT3 ...] option
would be nice, and would basically be equivalend to SVR4's
getdate() which parses date/time formats in-order until it
finds a match or reaches the end.

These latter two implementations would allow new formats
to be specified by new code, retaining 100% backward
compatability.

Sent via Deja.com http://www.deja.com/
Before you buy.



Sat, 13 Apr 2002 03:00:00 GMT  
 POLL: New 'clock scan' formats

Quote:

> I was pointed to a good doc on ISO time formats:
>         http://www.cl.cam.ac.uk/~mgk25/iso-time.html

> I would like people who find that 'clock scan' does not support enough
> standard formats to visit this page, and whatever other ref they have
> (like maybe SQL DB time formats), and then tell me what specific formats
> are important to you.

> We will be adding some new scan formats to the clock command, but if
> you delve into each that is discussed in the above link, you will find
> some sticky ambiguities that we'd rather avoid (especially anything
> that might change a currently valid scan format - we won't do that).

Rather than hiding these additions in the code, what about exposing them
at Tcl level (just a list of strings, the order being significant), and
simply adding the famous -format option ? (think of the - small, but
significant - Tcl-in-one-kilobyte community).

-Alex



Sat, 13 Apr 2002 03:00:00 GMT  
 POLL: New 'clock scan' formats

Quote:


> > I was pointed to a good doc on ISO time formats:
> >         http://www.cl.cam.ac.uk/~mgk25/iso-time.html

> > I would like people who find that 'clock scan' does not support enough
> > standard formats to visit this page, and whatever other ref they have
> > (like maybe SQL DB time formats), and then tell me what specific formats
> > are important to you.

> > We will be adding some new scan formats to the clock command, but if
> > you delve into each that is discussed in the above link, you will find
> > some sticky ambiguities that we'd rather avoid (especially anything
> > that might change a currently valid scan format - we won't do that).

> Rather than hiding these additions in the code, what about exposing them
> at Tcl level (just a list of strings, the order being significant), and
> simply adding the famous -format option ? (think of the - small, but
> significant - Tcl-in-one-kilobyte community).

Let me second that.  Spend the effort implementing "clock scan -format
..." rather than trying to find the subset of the unimplemented
formats which people want badly and can be compatibly integrated into
the auto scan algorithm.  As you say, there are ambiguities which
cannot be resolved by any automatic scan.

Hmm, maybe along with "clock scan -format ..." there should be a:

        clock scanformats ?format ...?

which specifies a list of formats to try in order until one succeeds?
As a yacc grammar, the current recognizer probably cannot be described
by such a list, or by a short one, but the local preferences that
anyone might want could be a manageable list.

-- rec --



Sat, 13 Apr 2002 03:00:00 GMT  
 POLL: New 'clock scan' formats

I missed the original posting, but obviously

Quote:

> > I was pointed to a good doc on ISO time formats:
> >         http://www.cl.cam.ac.uk/~mgk25/iso-time.html

> > I would like people who find that 'clock scan' does not support enough
> > standard formats to visit this page, and whatever other ref they have
> > (like maybe SQL DB time formats), and then tell me what specific formats
> > are important to you.

I hope we don't even have to vote about YYYY-MM-DD. One of its nicer
features are that a list of those can be sorted even as ascii-strings.

Harald Kirsch
--
P.S.: Never ever mail me copies of your posts.
---------------------+---------------------------------------------


     A no-smoking area in a restaurant is like a
     no-pee area in a swimming pool.



Sat, 13 Apr 2002 03:00:00 GMT  
 POLL: New 'clock scan' formats


:> Rather than hiding these additions in the code, what about exposing them
:> at Tcl level (just a list of strings, the order being significant), and
:Let me second that.  Spend the effort implementing "clock scan -format

I want to third that if possible.

:the auto scan algorithm.  As you say, there are ambiguities which
:cannot be resolved by any automatic scan.
:
:Hmm, maybe along with "clock scan -format ..." there should be a:
:
:       clock scanformats ?format ...?
:
:which specifies a list of formats to try in order until one succeeds?
:As a yacc grammar, the current recognizer probably cannot be described
:by such a list, or by a short one, but the local preferences that
:anyone might want could be a manageable list.

If something like a scanformats is used, perhaps there can be a way that
says 'go ahead and try the built in formats first, then try these...
That would save a lot of coding!

--

<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.



Sun, 14 Apr 2002 03:00:00 GMT  
 POLL: New 'clock scan' formats

Quote:

> I was pointed to a good doc on ISO time formats:
>         http://www.cl.cam.ac.uk/~mgk25/iso-time.html

> I would like people who find that 'clock scan' does not support enough
> standard formats to visit this page, and whatever other ref they have
> (like maybe SQL DB time formats), and then tell me what specific formats
> are important to you.

> We will be adding some new scan formats to the clock command, but if
> you delve into each that is discussed in the above link, you will find
> some sticky ambiguities that we'd rather avoid (especially anything
> that might change a currently valid scan format - we won't do that).

OK, there seems to be an outcry for a new -format switch.  This is
something that won't be done for 8.3, and isn't likely to be done
because it really isn't much more than:

        clock scan $date -format %d-%m-%Y

is      scan $date %d-%d-%d d m Y
        clock scan $m/$d/$Y

To do -format, we'd have to redo the entire scan command with special
time specific %-subs.  Instead, I am going to add as many unambiguous
formats from iso8601 as possible.  If time permits, I am going to add
a -iso switch that will kick in different grammars that distinguish
the ambiguous ones.  This is the easiest given the time alloted.  If
someone wants something else and gives me a patch, I'll consider it.

--
   Jeffrey Hobbs                          The Tcl Guy
   jeffrey.hobbs at scriptics.com         Scriptics Corp.



Sun, 14 Apr 2002 03:00:00 GMT  
 POLL: New 'clock scan' formats
:> I was pointed to a good doc on ISO time formats:
:>         http://www.cl.cam.ac.uk/~mgk25/iso-time.html
:>
:> I would like people who find that 'clock scan' does not support enough
:> standard formats to visit this page, and whatever other ref they have
:> (like maybe SQL DB time formats), and then tell me what specific formats
:> are important to you.
:>
:> We will be adding some new scan formats to the clock command, but if
:> you delve into each that is discussed in the above link, you will find
:> some sticky ambiguities that we'd rather avoid (especially anything
:> that might change a currently valid scan format - we won't do that).

: OK, there seems to be an outcry for a new -format switch.  This is
: something that won't be done for 8.3, and isn't likely to be done
: because it really isn't much more than:

:       clock scan $date -format %d-%m-%Y

: is    scan $date %d-%d-%d d m Y
:       clock scan $m/$d/$Y

: To do -format, we'd have to redo the entire scan command with special
: time specific %-subs.  Instead, I am going to add as many unambiguous

Why? There is POSIX function strptime, which already present in system
libraries. You rely on strftime for [clock format].

I suggest following approach:

If there is no -format option, use current code.
Fi there is one, just pass it to system strptime function.
Of course, you have to convert string from UTF8 to current system
encoding first.
--

I don't answer questions by private E-Mail from this address.



Tue, 16 Apr 2002 03:00:00 GMT  
 POLL: New 'clock scan' formats

Quote:

> If there is no -format option, use current code.
> Fi there is one, just pass it to system strptime function.
> Of course, you have to convert string from UTF8 to current system
> encoding first.

That is an interesting idea.  Perhaps a new -posix flag that will
just skip all the other stuff and go straight to strptime.  My
guess is that strptime doesn't handle any of the cute "yesterday"
"1 fortnight ago", etc (which most people don't really need, but
we need to support in the 'default' case for backwards compatibility).

--
   Jeffrey Hobbs                          The Tcl Guy
   jeffrey.hobbs at scriptics.com         Scriptics Corp.



Tue, 16 Apr 2002 03:00:00 GMT  
 POLL: New 'clock scan' formats

Quote:

> OK, there seems to be an outcry for a new -format switch.  This is
> something that won't be done for 8.3, and isn't likely to be done
> because it really isn't much more than:

Jeff, I would rather have an easy way to delta time. The kluges that I
have written to do delta times are many (see the {*filter*}I had to do in my
calendar program from my book to handle next month and such).

Just give me a nice easy way to do delta times (or time math) I can do
almost anything with "format" :-).



Wed, 17 Apr 2002 03:00:00 GMT  
 POLL: New 'clock scan' formats


:just skip all the other stuff and go straight to strptime.  My
:guess is that strptime doesn't handle any of the cute "yesterday"
:"1 fortnight ago", etc (which most people don't really need, but

A few years ago I worked with an author of either this package or one
quite similar discussing adding code all sorts of those types of extra parsing.

What: Remind
Where: <URL: ftp://ftp.doe.carleton.ca/pub/remind-3.0/remind-03.00.20.tgz>
Description: Remind is an alarm/calendar program which handles Roman
        and Hebrew calendars, sunrise, sunset and moon phases,
        is multilingual, does complicated date calculations (handling
        holidays propers), alarms, includes a WWW calendar server, and produces
        postscript output.  Uses Tk for an X front end.
        Available for UNIX, MS-DOS, OS/2 and other platforms.
Updated: 10/1999

--

<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.



Wed, 17 Apr 2002 03:00:00 GMT  
 POLL: New 'clock scan' formats
:> If there is no -format option, use current code.
:> Fi there is one, just pass it to system strptime function.
:> Of course, you have to convert string from UTF8 to current system
:> encoding first.

: That is an interesting idea.  Perhaps a new -posix flag that will
: just skip all the other stuff and go straight to strptime.  My
: guess is that strptime doesn't handle any of the cute "yesterday"
: "1 fortnight ago", etc (which most people don't really need, but
: we need to support in the 'default' case for backwards compatibility).

I'll suggest to use this approach wider.

Whenever possible rely on system functions, especially for l10n/i18n.
Of course, there is broken systems, which don't support some standard
features, but it is better to use code like current only as compile-time
option if configure detects that particular feature isn't supported by
system libs. It's main purpose of configure, isn't it?

If you'll use
strptime for clock scan,
nl_langinfo(CODESET) to detect initial encoding
iconv to convert between encodings etc,etc,

binary distributeion of Tcl for systems which support these features
would be much smaller and code would be more efficient.

I don't think that keeping two separate versions of code - for good
systems and for broken ones would place much additional burden on
Scriptics - version which works via underlying libraries would be
trivial and wouldn't require maintainance.

--

I don't answer questions by private E-Mail from this address.



Thu, 18 Apr 2002 02:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. Fwd: Re: SUMMARY Re: POLL: New 'clock scan' formats

2. Question clock's scan format

3. clock scan [clock format [clock seconds]] fails

4. Clock scan - clock format annoyance

5. Q: clock scan/clock format/timezone WET/Solaris

6. clock scan doesn't handle GMT+xxxx timezones

7. clock format %x doesn't work as documented

8. Clock format/scan converson - 1901

9. Clock scan on ISO-format time strings

10. rising_edge(clock) vs clock'event

11. Formatstring in 'Scan from String'

12. problem with Tcl 'scan'

 

 
Powered by phpBB® Forum Software