[tz] please do not enforce limits in code for time zones
Howard Hinnant
howard.hinnant at gmail.com
Mon Jan 22 19:22:21 UTC 2018
On Jan 22, 2018, at 1:55 PM, Steve Allen <sla at ucolick.org> wrote:
>
> On Mon 2018-01-22T18:47:07+0000 Stephen Colebourne hath writ:
>>> Does newer Java code (Java 9, ThreeTen-Backport) also have these
>>> limitations?
>> No. The biggest limit is that offsets are constrained to -18 to +18 hours.
>
> The traditional calendar for observing at Lick Observatory has always
> had days begin at local noon. This means that the time zone for the
> Lick calendar is 20 hours behind Greenwich. I implore all
> implementors to accommodate local time zones which are not limited to
> the list that is part of tzdb.
There’s a proposal before the C++ standardization committee:
https://wg21.link/p0355
<Disclaimer> I’m the author. </Disclaimer>
which supports _multiple_ types of time zones. It only has one type that is supplied by the standard, and that is a wrapper around the IANA time zone database. However users can relatively easily supply alternative time zones and have them work relatively seamlessly with the std::lib. For example here is an example custom time zone based on posix time zones:
https://github.com/HowardHinnant/date/blob/master/include/date/ptz.h
My point is to affirm Steve Allen’s comment above, that at least in C++, we are aiming to allow for things such as the Lick calendar, even if only as user-written customizations.
Howard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/tz/attachments/20180122/6274c73b/signature.asc>
More information about the tz
mailing list