Jakarta is Indonesia West Time Not Central Time

Robert Elz kre at munnari.OZ.AU
Thu May 14 12:05:26 UTC 2009

    Date:        Thu, 14 May 2009 11:56:33 +0100
    From:        Tim Diggins <tim at red56.co.uk>
    Message-ID:  <79758C11-AD60-45D1-B8D1-6D99B743368C at red56.co.uk>

  | If I have followed what you're saying, shouldn't the tzdata make sure  
  | to use abbreviations that are already current, where these exist,  
  | rather than inventing new ones?

Perhaps - wherever they're already current in English anyway (there's
so much more that we don't do as part of this project to deal with other
languages, and cultures.)   If there are places where an English tz abbr
is really well defined (so exclude all the Aust stuff where we just keep
arguing about what people actually use) and different from what the tz
database includes, then we probably need to know about it.

  | Speaking as an application designer, it's a real shame one can't work  
  | out the 'actual' timezone (as opposed to the current UTC offset) from  
  | the output of formatted time strings, but I suppose there's not a lot  
  | we can do about that now.

That's just a matter of the applications outputting enough data do that -
so the timezone can be (re-)determined later.   The problem is more likely
that you want to be able to do it from the same data that is being produced
to present to humans, and for that, timezone selection data is unlikely to
be included.  People just don't want to know that level of detail - all
they care about is "what time was it there?" and 'what time was it here?"
(or just one of those in some cases) - anything more than that is simply
too much information for almost every purpose (calendaring applications
often need "what time was it (or will it be) in some random other set of
places?" as well of course, but that's all just more of the same.

And of course, from just that, there's not enough info to select a
timezone, for which we need more than just the relative differences
between the local timestamps in two arbitrary places on earth.
It doesn't matter how you would encode the extra data, people
generally don't want to see it, so it won't be there.

Of course, if you have somewhere you can keep data that isn't being used
to display to humans, then including the timezone name should be trivial
(I'd hope that a calendaring application able to schedule repeating
events for a wide area audience would include this kind of thing - as
should anything doing long distance timetabling (planes, trains, ...), etc).

It would help if we (the world) really had some true standard for timezone
names of course.


More information about the tz mailing list