> Date handling on plan 9 is almost adequate today if you don't
> have to parse dates or deal with timezones, and don't do
> multithreading. Otherwise, it's difficult to get right, and
> we often don't.
I should have said -- I'm hoping to get some feedback.
The best feedback would be "I don't see how I'd do <thing>",
or "It seems like <manipulations>" would be error prone or
fragile.
Another problem that I'm not sure how to deal with is that
right now, our timezone database format has two issues:
First, it has no way of mapping from an abbreviated zone.
For example, EST should map to /adm/timezone/US_Eastern,
but that information requires a search of all timezones.
Second, even if we did search all timezones, we're hard
coding a timezone name length of 3, which means that
EST is ambiguous: It maps to US_Eastern, but it also
is used as the name for AEST (Australian East), BRT
(Brazil), and Jamaica.
As a result, if we have a timestamp like this:
Jan 1 2013, 7:00 PM EST
will not be able to deal with the timezone component.
Extending the length of the name in our current timezone
files will break old binaries that use localtime, since
they'll return an error on timezone naming.
I'm wondering if there are clean approaches to deal
with this.
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T5b9f56a5fac852c2-M7cb10fc9054e58014db26d3f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
