[tz] please do not enforce limits in code for time zones

[Howard Hinnant]

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>