Re: TIP #173: Internationalisation and Refactoring of the 'clock' Command
From: Kevin Kenny (kennykb_at_acm.org)
Date: 03/17/04
- Next message: David N. Welton: "Re: Future work on Tk questions"
- Previous message: Benjamin Riefenstahl: "Re: TIP #172: Improve UNIX Tk Look and Feel"
- In reply to: Arjen Markus: "Re: TIP #173: Internationalisation and Refactoring of the 'clock' Command"
- Next in thread: Arjen Markus: "Re: TIP #173: Internationalisation and Refactoring of the 'clock'Command"
- Reply: Arjen Markus: "Re: TIP #173: Internationalisation and Refactoring of the 'clock'Command"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 17 Mar 2004 10:40:00 -0500
Arjen Markus wrote:
> 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)
24:00 will be accepted on input as the end of the day, but
will never be produced on output. I'll clarify that
the default time of day for [clock scan] is
"midnight - the start of the day - in the given time
zone."
>> In all of the foregoing discussion, the 'base date', 'base month',
>
>
> -- the same text appears above.
Will fix, thanks.
> If I say:
>
> clock add $time 10000000000
>
> is the argument then automatically converted into a wide integer?
> Or is [expr {wide(...)}] needed?
While I don't promise to fix all the existing bugs with
conversions to wide, I promise not to introduce new ones!
The intent is that the argument is interpreted as a wide
integer. If the same literal was previously interpreted
as a 32-bit integer, it won't work until Bug #868489 is
fixed.
>> 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)
The issue isn't one of ambiguity, but rather one of definition.
Consider a locale where 01:59:59 (Standard Time) is followed by
03:00:00 (Summer Time). What is the time 25 hours after 01:30?
It's 03:30 the next day. But "1 day 1 hour" after 01:30 is
"1 day after 01:30" (01:30 the next day) plus another hour (02:30).
The rule of applying each difference one at a time in the order
specified allows the programmer to choose the interpretation.
>> %D: Synonymous with %m/%d/%Y. Should be used only in US locales.
>
> Hm, no abbreviation for "%Y-%m-%d" - the ISO standard?
It's there for compatibility with existing code. %D, %T and %r
are all US-centric; %X, %x, %EX, and %Ex are the correct way to
format dates in a locale-specific manner.
>> %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
Again, I'm not changing the spelling of this one. It's in the
existing code.
> Could you explain in which respects this new clock command is
> incompatible with the current one?
It has fewer bugs. :) It also supports a lot more options.
Seriously, code that uses only the old format groups, and
doesn't use any of the new options (-locale, -timezone,
...) shouldn't see any differences. The old test suite
passes against the new command.
> 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?
There's a hook in the code (with nothing hung on it) for
a locale alternative calendar. Each of the calendars
that I mentioned (including the Hijri [Islamic] calendar)
divides the year into months, and the month into days.
The lunisolar calendars have a thirteenth month in some
years, but there is nothing in the generic code that
presumes a 12-month year; that's all in the stuff
specific to the Gregorian calendar. I would presume
that in an Arabic locale, the %E groups would be used
to select the Hijri month and day, and the %EY would
be the year of the Hegira.
I included the Japanese calendar in the initial set because
(1) it's easy, being based on the Gregorian calendar, and
(2) it's needed for government documents in Japan.
-- 73 de ke9tv/2, Kevin
- Next message: David N. Welton: "Re: Future work on Tk questions"
- Previous message: Benjamin Riefenstahl: "Re: TIP #172: Improve UNIX Tk Look and Feel"
- In reply to: Arjen Markus: "Re: TIP #173: Internationalisation and Refactoring of the 'clock' Command"
- Next in thread: Arjen Markus: "Re: TIP #173: Internationalisation and Refactoring of the 'clock'Command"
- Reply: Arjen Markus: "Re: TIP #173: Internationalisation and Refactoring of the 'clock'Command"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
