Re: TIP #173: Internationalisation and Refactoring of the 'clock' Command

From: Arjen Markus (arjen.markus_at_wldelft.nl)
Date: 03/17/04

  • Next message: ulis: "Re: Namespace confusion" 
    Date: Wed, 17 Mar 2004 09:09:09 +0100

    Kevin Kenny wrote:
    >
    > TIP #173: INTERNATIONALISATION AND REFACTORING OF THE 'CLOCK' COMMAND

    > SPECIFICATION
    > ===============
    >
    > The [clock] command shall be reimplemented as an ensemble [TIP #112],
    > with most of the subcommands implemented in Tcl. A minimal set of the
    > existing C code shall be refactored and placed inside a *::tcl::clock*
    > namespace. The existing subcommands *seconds* and *clicks* shall be
    > exposed. The existing *scan* shall be hidden inside the namespace.
    > [clock scan] and [clock] format shall be reimplemented in Tcl. In
    > addition, new [clock add] and [clock subtract] commands shall be added.
    >
    > The syntax and semantics of the [clock clicks] and [clock seconds]
    > commands will remain unchanged.
    >
    > SPECIFICATION: CLOCK SCAN
    > ===========================
    >

    >
    > None of the above:
    > If none of the above indicators is present, midnight in the given
    > time zone is used.
    >

    I take this is the _beginning_ of that day?
    Could you clarify if:

    0:00 is the beginning of the day
    24:00 is the end of the same day

    (this seems to be rather intuitive, but it does make "midnight" an
    ambiguous moment)

    > In all of the foregoing discussion, the 'base date', 'base month',

    -- the same text appears above.

    >
    > SPECIFICATION: CLOCK ADD, CLOCK SUBTRACT
    > ==========================================
    >
    > These two commands perform arithmetic on dates and times. The syntax
    > is:
    >
    > clock (add|subtract) time ?count unit?... \
    > ?-gmt boolean? ?-timezone timeZone? ?-locale name? ?-
    >
    > It accepts a time, expressed in seconds from the Posix epoch of 1
    > January 1970, 00:00 UTC, and adds or subtracts units of time from it
    > according to the alternating *count* and *unit* parameters. Each
    > *count* must be a wide integer; each *unit* is one of the following:
    >

    If I say:

       clock add $time 10000000000

    is the argument then automatically converted into a wide integer?
    Or is [expr {wide(...)}] needed?

    > years year months month
    > weeks week days day
    > hours hour minutes minute seconds second
    >

    > There are subtle differences in many cases between adding seemingly
    > similar offsets. For instance, on the day before Daylight Saving Time
    > goes into effect, adding 24 hours will give "the time 24 hours from the
    > base time, irrespective of any clock change", while adding 1 day will
    > give "the time it will be at the same time of day on the following
    > day." Similarly, adding 1 month on 30 January will give either 28 or 29
    > February. There are equally strange effects when performing date/time
    > arithmetic across the change between the Julian and Gregorian
    > calendars.
    >

    Perhaps there should be a "query" facility to see if the offset is
    ambiguous ... Maybe this problem will not arise in practice but I
    can imagine that one might want to know it. (User input could cause
    surprises for instance)

    > SPECIFICATION: FORMATS
    > ========================
    >

    >
    > %D: Synonymous with %m/%d/%Y. Should be used only in US locales.
    >

    Hm, no abbreviation for "%Y-%m-%d" - the ISO standard?

    >
    > %l: On output, produces the number of the hour on a 12-hour clock
    > (12-11) without a leading zero. On input, matches one or two
    > digits and may be used to determine time of day.
    >

    I suggest using %L to avoid visual confusion with %I

    > BUGS
    > ======
    >
    > The reference implementation does not attempt any calendars not based
    > on the hybrid Julian/Gregorian calendar. This implementation is
    > adequate for the Western countries and for the Japanese civil calendar,
    > but does not address the Hijri, Hebraic, Thai, Chinese or Korean
    > calendars. (No Tcl user has requested these, to the best of the
    > knowledge of the author of this TIP.)
    >

    Could you explain in which respects this new clock command is
    incompatible
    with the current one?

    Just a hypothetical question: how hard would it be to implement a
    different calendar system, say a calendar based on the moon, like the
    Arabic countries have?

    Regards,

    Arjen

  • Next message: ulis: "Re: Namespace confusion"

    Relevant Pages

    • Re: shortest day
      ... :>: incapable of assembling a decent calendar. ... candle clock... ... The shortest day depends on location. ... The Wild Wild West was far beyond the Romans -- you're comparing ...
      (sci.physics)
    • Re: Calendars tasks and resources
      ... The might well be people working around the clock during an outage but does an individual person - Catfish Hunter, for example - work around the clock without any time off for sleep or meals? ... The 24 hour calendar says that once they start that job, the two Cats aren't relieved by anyone else for any reason and they don't go home until the job is done. ... up a resource for "boiler makers working 6-10's, ...
      (microsoft.public.project)
    • Re: shortest day
      ... :>: incapable of assembling a decent calendar. ... :> When big white ball has gone, ... :> When big white ball reappears, note time. ... candle clock... ...
      (sci.physics)
    • Re: tcl interp inside vim throws error w/ clock format
      ... Rebuilt vim 7.1 with tcl 8.4.15. ... I looked into the clock.tcl file that exports the clock commands into ...
      (comp.lang.tcl)
    • Re: Trial to Full Version?
      ... You set the calendar back 10 days...you now have 350 days because the ... You set the clock forward 10 days to the correct date...you now have ... Are you suggesting if the date is changed ... > day) the server is locked out? ...
      (microsoft.public.windows.server.migration)