Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202101.tar.gz
size: 765257 bytes
md5: 87d3365828cc874464e4da79dee03f4d
sha1: ba94229fb25886df0025540c4ae8b61a3853e8e0
Changes from the previous release:
* Olson database version 2021a
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202006.tar.gz
size: 765335 bytes
md5: a0e9272e175772ac571b9e4c0494dff6
sha1: d4ae70d560979545071e6ac7dff24a0afe90816e
Changes from the previous release:
* Olson database version 2020f
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202005.tar.gz
size: 765139 bytes
md5: 04a8778d23734a86fea8966bab865e72
sha1: c635bb24b2b515268d3a93aad850e94eda20746b
Changes from the previous release:
* Olson database version 2020e
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202004.tar.gz
size: 752210 bytes
md5: 89639f92b77676aa60c46d87ee0462ab
sha1: b362be449e0d10d4141fb9553c59da89109f584e
Changes from the previous release:
* Olson database version 2020d
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202003.tar.gz
size: 751008 bytes
md5: 9337589dd5ca3482eec4e84e6bdb31d6
sha1: 2c023ee079e93c68ea833b502654eac8ea6f6ea3
Changes from the previous release:
* Olson database version 2020c
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202002.tar.gz
size: 750088 bytes
md5: e3c552ce6eaa65d83bd9bc778d93d56c
sha1: 2e520e2000c20e9478becfdad496e9751268f065
Changes from the previous release:
* Olson database version 2020b
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.202001.tar.gz
size: 806724 bytes
md5: 076b0e74277f3c40f139fd29b24bbca4
sha1: 07fb6502cf01b0e6f76f2a0d14f36b31f356631d
Changes from the previous release:
* Olson database version 2020a
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201903.tar.gz
size: 799872 bytes
md5: 539cef4a4cbba7800a40dd69b5f3b8ea
sha1: 0a740049a23a1ffa82161649b63ca645e0a4c540
Changes from the previous release:
* Olson database version 2019c
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201902.tar.gz
size: 790741 bytes
md5: 13ba3af683256e78610d7198d2a6b097
sha1: 460a25632b34ad6d074b1abbc3537abf2710ec48
Changes from the previous release:
* Olson database version 2019b
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201901.tar.gz
size: 783469 bytes
md5: 409c69258d5ed63f134d0f80454baf57
sha1: 2d045e8a27c6444d5b96bc32b59f46da70729566
Changes from the previous release:
* Olson database version 2019a
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201809.tar.gz
size: 778806 bytes
md5: 0be3d73258dcc6ce3e695f06fbd7d5c3
sha1: d85dbedca1f4c1a53faccc6c8e3f8a685e3717ef
Changes from the previous release:
* Olson database version 2018i
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201808.tar.gz
size: 778286 bytes
md5: 6d160f33659c27e788fea6c99821c046
sha1: cc1a48e43bd43ce217a8d4887b422252156db27c
Changes from the previous release:
* Olson database version 2018h
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201807.tar.gz
size: 764928 bytes
md5: 616ac029cbf91238b8279c15927ef10c
sha1: af5f4098a1c4c2e5cd515fa6717fbba1722ba6f5
Changes from the previous release:
* Olson database version 2018g
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201806.tar.gz
size: 761285 bytes
md5: 02ad00dbeb0cd3e8175d7678f062289c
sha1: ae3f9ffb9e1b3f2d282bd8b1cd75be9f2ed3ad0a
Changes from the previous release:
* Olson database version 2018f
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201805.tar.gz
size: 747739 bytes
md5: 23c77b0e3f74758ad1d29e836b4b1dd3
sha1: be3f900c2b8beb518a1eaafa2cec5f178aee81e2
Changes from the previous release:
* Olson database version 2018e
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201803.tar.gz
size: 730796 bytes
md5: 3b8ab43a8f588a532faf40986f825121
sha1: 45a18a0e4747be1396445e01e13d31bf46df25f5
Changes from the previous release:
* Olson database version 2018c
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201802.tar.gz
size: 729629 bytes
md5: 9599533ff132a3622bc622cbaa7d4d72
sha1: 12044d4b72a6cff5fe19f5985390141183f08b9f
Changes from the previous release:
* Olson database version 2018b
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201801.tar.gz
size: 728913 bytes
md5: d37ff1a893c521afba3d2ef7494af45d
sha1: f07f4f450b22c59f7740e70146b9458ef3c343ba
Changes from the previous release:
* Olson database version 2018a
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201703.tar.gz
size: 737648 bytes
md5: f9c045c0bbcc24f9e5cb9f164884951b
sha1: a1897682fbd3f7ec0d4dfd88c670a5d8694e404a
Changes from the previous release:
* Olson database version 2017c
I wrote:
>Shortly available from all good CPAN mirrors:
>
> file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201702.tar.gz
I've revived the automatic repackaging which broke back at the 2014h
release, nearly three years ago. It originally broke then because the
new trend to turn
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201702.tar.gz
size: 721268 bytes
md5: e60e2f96eb2c2d501fb4468e5ec8d379
sha1: 8cd2303725b607db99487b31cd934122ef10bd93
Changes from the previous release:
* Olson database version 2017b
ambiguity) yield more than one offset. Non-existent local times
(skipped due to clocks going forward) yield an empty list without error.
-zefram
rmat, and all the software I know about, can handle transitions
at any second.
-zefram
Binarus wrote:
>Did you memorize the tzfile of 1969 :-)
I looked through the Olson source files. I could also have automated
a search through the compiled zone data.
-zefram
he earlier
>one (provided the clock is turned back by an hour when switching back).
You can't rely on offset changes, even specifically ones for DST, being of
an hour. Australia/Lord_Howe (Lord Howe Island) does a regular half-hour
DST jump.
-zefram
fset 2 hours to the west). Historically,
Africa/Casablanca (Morocco) changed 12:00->13:00 in a DST change in 1967.
And Pacific/Kwajalein (part of the Marshall Islands) jumped across the
international date line in the unfashionable direction, repeating 23
hours of 1969-09-30.
-zefram
whether DST is in effect. Giving both states
of that flag gives you two UT times, which you can then convert back
to local to check whether they come out with the same DST flag state.
This will work for regular DST changes, but not for offset changes that
are unrelated to DST.
-zefram
perls,
and are individually easy to fix, so the problem is still manageable on
those perl versions.)
-zefram
23 }; return 456; } print z()'
456
$ perl -MTry::Tiny -lwe 'sub z { try { return 123; }; return 456; } print z()'
456
$ perl -MTryCatch -lwe 'sub z { try { return 123; } return 456; } print z()'
123
-zefram
right tool for the job.
-zefram
things worse. For subclassing to be the right answer,
the objects of your classes would have to be everything that DateTime
objects are, plus something that you're adding. But one of the things
that DateTime objects are is Gregorian, which your objects are not.
-zefram
Eric Brine wrote:
>Thanks. I'll study this. I didn't think dividing by 60, adding 60 and
>subtracting 60 was safe before of leap seconds.
POSIX time, what DateTime calls "epoch" time, doesn't count leap seconds.
Each multiple of 60 corresponds to the top of a UTC minute.
-zefram
my($tgt_date_str, $zone_name) = @ARGV;
my $zone = DateTime::TimeZone->new(name => $zone_name);
print start_of_day($tgt_date_str, $zone), "Z\n";
-zefram
Eric Brine wrote:
>00:00:04 <--- Starting from this
You shouldn't be getting such a time at any point in the algorithm I
was proposing.
-zefram
While changing the effective length of a
local day is quite palatable, making a day discontinuous is too big an
inconvenience. Note that this is inconvenient *for people in the zone*,
unlike things like there being no local 12:00, which is inconvenient
*for programmers* and happens all the time.
-zefram
r this part, you just take the current UT time and represent it in
zone terms. That tells you what month to default to.
-zefram
an
>hour boundary and simply try incrementing hours until no more exceptions.
That's a bad assumption. You can assume *minute* boundaries, but
not hours.
-zefram
day morning. This year the last Thursday in March was
the last day in March, so the affected Friday was the first day of April.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201407.tar.gz
size: 665182 bytes
md5: b999f49116bedeecab69e1c9bad98282
Changes from the previous release:
* Olson database version 2014g (code 2014g, data 2014g): 405 canonical
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201406.tar.gz
size: 649615 bytes
md5: a1e6af771fe58f17a0c03636c3da0725
Changes from the previous release:
* Olson database version 2014f (code 2014f, data 2014f): 414 canonical
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201403.tar.gz
size: 646013 bytes
md5: 17909ab88ec08fad82d5728c75d19ff1
Changes from the previous release:
* Olson database version 2014c (code 2014c, data 2014c): 425 canonical
the
entire calendar day as the island switched from the eastern side of the
International Date Line to the more fashionable western side.
You must select some alternative behaviour to follow on days when the
desired local time doesn't exist.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201402.tar.gz
size: 647194 bytes
md5: 8926e5c7bb441ef37a394664bf6452a0
Changes from the previous release:
* Olson database version 2014b (code 2014b, data 2014b): 425 canonical
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201401.tar.gz
size: 644845 bytes
md5: eb18772b27091fc69e20ccf07a00e430
Changes from the previous release:
* Olson database version 2014a (code 2014a, data 2014a): 424 canonical
Eric Brine wrote:
I posted a solution here:
http://stackoverflow.com/a/20850899/589924
That message states
|On the DateTime mailing list, Zefram suggested I do a binary search on
|the time zone data. The following is an implementation of that solution:
which is not correct. I did not suggest
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201308.tar.gz
size: 666258 bytes
md5: bb41c9631003dc66b95c773efe09da3b
Changes from the previous release:
* Olson database version 2013h (code 2013h, data 2013h): 427 canonical
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201307.tar.gz
size: 664500 bytes
md5: 5f6d1a60b22e72d6b76a6477dcd9afdf
Changes from the previous release:
* Olson database version 2013g (code 2013g, data 2013g): 427 canonical
in that regard.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201306.tar.gz
size: 583400 bytes
md5: 98d834be02907395d61ad88039b9ba9a
Changes from the previous release:
* Olson database version 2013f (code 2013f, data 2013f): 427 canonical
for DT:TZ 2. I think it's the
only blocker atm.
-zefram
Time-OlsonTZ-Data-0.201305 has the prebuild features that you requested.
You should be OK to incorporate it into the tzdata process now.
-zefram
Another new version of my DT:TZ rewrite. CPAN-style tarball at
http://www.fysh.org/~zefram/tmp/DateTime-TimeZone-1.902.tar.gz
Public git repo at
git://lake.fysh.org/zefram/DateTime-TimeZone.git
The zic issues affecting a couple of zones have now been resolved.
My zic patches were accepted
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201305.tar.gz
size: 583635 bytes
md5: 4acdae056f145eef8e7e0eac9eae1844
Changes from the previous release:
* Olson database version 2013e (code 2013e, data 2013e): 427 canonical
the
behaviour of delta_days. It's up to the user to decide which kind of
comparison to do.
-zefram
project, for insight into the design.
-zefram
intrigeri wrote:
Does it make sense? Did we miss anything? Any better idea?
Your plan is essentially good. I'll put the hooks you want into the
prebuild script.
-zefram
-timezone.)
-zefram
current local
time and compare that (sans timezone) against the stored local time.
-zefram
::Data.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201210.tar.gz
size: 592407 bytes
md5: 138a1802d50d8315475b66f2c9811f0a
Changes from the previous release:
* Olson database version 2012j (code 2012j, data 2012j): 440 canonical
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201209.tar.gz
size: 593422 bytes
md5: 250e48cb102b840a6c711989260fed53
Changes from the previous release:
* Olson database version 2012i (code 2012i, data 2012i): 440 canonical
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201208.tar.gz
size: 592816 bytes
md5: 094b652d130622d0e325fb015f96e256
Changes from the previous release:
* Olson database version 2012h (code 2012h, data 2012h): 440 canonical
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201207.tar.gz
size: 587575 bytes
md5: 659a8598a10f5a51b82d9b01427f4708
Changes from the previous release:
* Olson database version 2012g (code 2012g, data 2012g): 440 canonical
the timezone slot explicitly.
Relying on the floating default is acceptable, but being explicit
about it is better.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201206.tar.gz
size: 587874 bytes
md5: b6892ccf06bb28ff7b586d3bc9a2841e
Changes from the previous release:
* Olson database version 2012f (code 2012e, data 2012f): 440 canonical
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201205.tar.gz
size: 583552 bytes
md5: c77eabed1337d4fe576b13231180eb7d
Changes from the previous release:
* Olson database version 2012e (code 2012e, data 2012e): 440 canonical
be detected with -can, so you can get a clean error message when trying
to use it with a timezone class that doesn't support it.
-zefram
-21T01:30:00
If you're going to advertise this feature as find the next valid local
time, you need to handle cases like this correctly.
-zefram
.
Now however the second
change in 2012 is coming up one second short,
Smells like a leap second issue. There's a leap second scheduled for
2012-06-30T23:59:60Z.
-zefram
Carl Vincent wrote:
$ DateTime::Format::ISO8601-parse_datetime('2012W144T10:39+');
2012-04-05T10:39:00
Oh, well spotted, that's entirely inconsistent. The input could correctly
be 2012-W14-4T10:39+00:00 or 2012W144T1039+.
-zefram
to the
dotted-octet representation of IPv4 addresses, described in some detail
at http://www.fysh.org/~zefram/text_rep/draft-main-ipaddr-text-rep.txt.
Since these formats are out there in use, it would be better for the
module to parse them
Best for *a* module to parse them. A module that doesn't claim
). With the time of
day expressed as 10:39:00.000, the UT offset should be expressed as
+00:00, not +. So an ISO 8601 parser is justified in rejecting
10:39:00.000+.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201203.tar.gz
size: 583082 bytes
md5: 83fba384d3de2f3b763ed4870223e1dd
Changes from the previous release:
* Olson database version 2012c (code 2012b, data 2012c): 440 canonical
to
switch. There are enough 1.xx version numbers left for another couple
of years.
I'll suggest September 1 as the cutover date when Zefram will release
DateTime::TimeZone 2.00 using the new code base.
Works for me. There's one remaining unresolved item, the zic bugs,
but if that's not resolved
://www.fysh.org/~zefram/tmp/Time-OlsonTZ-Data-0.20120201.tar.gz is
a test version of the module distribution, which bundles (the important
parts of) the Olson database source, and the automation to build the
tzfiles, as well as bundling the prebuilt tzfiles. I can't not bundle
the tzfiles, because
consider what resolution you're really after. If you want
your timestamps to be sub-second meaningful then you need to be clear
about which flavour of UT you're using (probably UTC, in which case you
need to handle leap seconds properly).
-zefram
New version of my DT:TZ rewrite. CPAN-style tarball at
http://www.fysh.org/~zefram/tmp/DateTime-TimeZone-1.901.tar.gz
Public git repo at
git://lake.fysh.org/zefram/DateTime-TimeZone.git
I believe this version resolves all the issues that people raised with
1.900. Comments welcome, of course
I've created public git repositories for my datetime-related Perl modules:
git://lake.fysh.org/zefram/DateTime-TimeZone-SystemV.git
git://lake.fysh.org/zefram/DateTime-TimeZone-Tzfile.git
git://lake.fysh.org/zefram/DateTime-TimeZone-Olson.git
git://lake.fysh.org/zefram/App-olson.git
git
Anthony Ball wrote:
a way to query when the DST changes happen.
That'll need additions to the API for the timezone objects. I've got
some plans to do that, but it's a later stage.
-zefram
real dependency
on DateTime.
-zefram
going to handle them by a radical
refactoring that yields more of a query language than this collection
of options.
-zefram
#!perl
{ use 5.006; }
use warnings;
use strict;
use Date::ISO8601 0.000 qw(present_ymd);
use DateTime::TimeZone::Olson ();
use DateTime::TimeZone::SystemV ();
use DateTime
is over.
-zefram
it ought to additionally support.
-zefram
#!perl
{ use 5.006; }
use warnings;
use strict;
use Date::ISO8601 0.000 qw(present_ymd);
use Date::JD 0.005 qw(rdn_to_cjdnn);
use DateTime::TimeZone::Olson ();
use Getopt::Std qw(getopts);
use Params::Classify qw(is_string);
use Time::OlsonTZ::Data ();
use
nicer, in that day addition *is* associative. Of course, a quarter
of the time (when the 365 days spans a leap day), the 365-days-later
won't be the same-date-next-year. Is that what you mean by the leap
year problem?
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201201.tar.gz
size: 215399 bytes
md5: e6556bbb924abb7f8e018d58c66df700
Changes from the previous release:
* Olson database version 2012a (code 2012a, data 2012a): 440 canonical
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201202.tar.gz
size: 215450 bytes
md5: c30730b5e92d47a5a5e6fbb0a3ed2481
Changes from the previous release:
* Olson database version 2012b (code 2012b, data 2012b): 440 canonical
silly format for this. If you're concerned about
the size, just gzip it.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201114.tar.gz
size: 215462 bytes
md5: 816ca2268b8d743235832b507c5f4b62
Changes from the previous release:
* Olson database version 2011n (code 2011i, data 2011n): 439 canonical
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201113.tar.gz
size: 215785 bytes
md5: 85a8dd756e92ec89b09dd65d1bbca7ba
Changes from the previous release:
* Olson database version 2011m (code 2011i, data 2011m), with one-off
fix
, independent of the host's native timezone database.
DT:TZ:Local is about matching host behaviour, and with DT:TZ:Tzfile
available it should be fairly easy to get it reading /usr/share/zoneinfo.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201112.tar.gz
size: 214778 bytes
md5: fcfc9e47de53ee49d4f1f417add98f4b
Changes from the previous release:
1
-zefram
. I'm treating such releases as
canonical versions of the Olson database. Dave Rolsky has indicated
to me that he's likewise accepting them for the purposes of making new
versions of DT:TZ.
-zefram
-complete IETF work to establish a long-term process
for maintenance of the database.
-zefram
if you weren't previously intending to subscribe
to tz@elsie.
-zefram
-bit version of the file, which is exactly what
DT:TZ:Tzfile does. I'm treating this as a showstopper for replacing
DT:TZ. I've reported the problem to the Olson folks.
-zefram
to distinguish between the two philosophies.
Thanks for your comments.
-zefram
Karen Etheridge wrote:
So, if you're not going to generate a pod that contains this list at build-
or install-time, please provide an executable (App::Cmd is nice!) that
generates the list on the fly.
Thanks for the comments. I'm leaning towards the command-line tool
approach.
-zefram
switching from the Julian Calendar
(as used by Russia) to the Gregorian Calendar (as used by the US).
-zefram
attention. So I don't see any situation
where you'd validly use co-maint that you have only via this handover
arrangement, but I can't sensibly deny it.
-zefram
of the candidates (on what basis I
don't know) and either use the zone as a whole or apply its DST rules
while staying within the POSIX limits of what the zone spec could mean.
This could potentially be useful default behaviour somewhere within DT:TZ.
-zefram
1 - 100 of 238 matches
Mail list logo
