More syntax reference. I've done a quick survey of interpretations
of $TZ. I'll also throw in a couple of formats not used in $TZ.
glibc tzset() interpretation of $TZ
---
Accepts a subset of POSIX format. Does not document (but does support)
the option to omit
Eugene van der Pijll wrote:
OK, so a legal Europe/London timezone is meaningful (though not really
useful). As long as you're not proposing to change the Europe/London
timezone itself.
I'd initially imagined actually changing Europe/London, but on reflection
I realised that would be awfully
For reference, the POSIX definition of $TZ syntax is at
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html.
In summary, POSIX defines the meaning of $TZ strings matching $posix_tz
below:
$abbrev = qr#[A-Za-z]{3,}|\[-+0-9A-Za-z]{3,}\#;
$offset =
Zefram schreef:
It also explicitly lists some that are based on GMT: the European Union,
I don't think this is actually true. The page quotes a European
directive on summer time. Directives of the European Union are published
in all official languages of the EU, and all of the versions are
Zefram schreef:
I note that DT::TZ::TAI
attempts to treat TAI as a timezone, which doesn't work 100% but does
put TAI in roughly the right relationship to the other DT objects.
As you say, TZ::TAI does not work 100% prefectly. It has turned
out to be impossible to implement it correctly,
Eugene van der Pijll wrote:
If I were to implement these time scales for DateTime, I would probably
implement them as subclasses of UT1 (or LMT) and LAT, with the
geographical longitude as parameter; LMT+46d43m27s for Riyadh legal
time, for example. But your notation is reasonable as well.
Eugene van der Pijll wrote:
Civil time in the UK is not legally based on UTC;
I believe this to be incorrect. British Standard Time, aka
Europe/London, certainly observes leap seeconds, and is therefore
based on UTC. Maybe the legal definition is still in terms of GMT,
(The name British
Rick Measham wrote:
my $riyadh_lmt = DateTime::TimeZone::LMT-new(
longitude = 46 + (43 / 60) + (27 / 3600)
);
How much error in time conversions is introduced by the floating point
rounding?
A thought: it might be good to somehow include the ability to load other
TZ modules from a string.
Eugene van der Pijll wrote:
it's the difference
between GPS and TAI(GPS) that is fixed, right?
Forgot to reply to this earlier.
Yes, strictly speaking the equation is
TAI(GPS) = GPST + 19 s
I've been using the term GPS time slightly
Zefram schreef:
So *legally speaking* the standard time in the UK is based on what we
now call UT1. It is an astronomical timescale.
I've read some of the relevant parliamentary debates now, and you're
right. That still doesn't mean that our TZ Europe/London should be based
on UT1: the time
Zefram wrote:
Rick Measham wrote:
my $riyadh_lmt = DateTime::TimeZone::LMT-new(
longitude = 46 + (43 / 60) + (27 / 3600)
);
How much error in time conversions is introduced by the floating point
rounding?
DateTime allows for a one-second precision in the offset, so while LMT
passes a
I'm developing some code that provides a real-time clock display,
in conventional hours-minutes-seconds format, and handles multiple
time scales as well as ordinary UTC-based timezones. As a result,
I need a way for users to textually specify which time scale to use.
I'd like this syntax to be
12 matches
Mail list logo
