[tz] please do not enforce limits in code for time zones
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
>> 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:
<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:
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Message signed with OpenPGP
More information about the tz