tz VS compact-time

A link was added from "Europe/Kiev" to "Europe/Kyiv" in the included-by-default backward file [0], so that any user that doesn't exclude that file will simply treat the old name as an alias for the new name.

[0] https://github.com/eggert/tz/commit/e13e9c531fc48a04fb8d064a...

timeZone: Determines the current timezone to use to display the time e.g. America/Los_Angeles. Full list can be found on IANA time zone database

"Eire" is in there, for instance, to deal with software that assumes that the "is_dst" half of the year is during the (northern) summer, but Ireland technically does it the other way around -- a distinction relevant only to computers.

https://github.com/eggert/tz/blob/c3e966c59b02b1f47f0b7b0e4a...

The only other timezone that currently has a non-1h offset for DST -- Ireland's is -1 hours -- is Australia/Lord_Howe, which has a 30-min positive leap.

Prof Paul Eggert is currently the editor and coordinator of the Time Zone Database of IANA, which enables timestamps on official documents and photos.

I've looked at it, but wanted to work with the tz source repository directly (I think local-time gets their zone files from Ubuntu). Also getting zic running in a portable way seemed too much of a hassle. The text file format is not all that complicated and documented in the zic manual pretty well. This approach is also chosen by the JDK as far as I can tell.

Subscribe to tz-announce for more fun: https://www.iana.org/time-zones

Unfortunately, you just wait. The person(s) at IANA who manages The Time Zone Database is certainly aware, and from there it "just" has to percolate down to Google and your phone.

most systems use https://www.iana.org/time-zones

And have you looked at the TZ database? My God it's a hot mess, and for good reason: human governments are terrible at creating code. Worse even than beginning CS students, because at least CS students know they don't know what they're doing, while politicians are both stupid and arrogant enough to think they're not stupid.

https://concise-encoding.org/ will be released this year and has been in development for 5 years. This one has been slow because of all the support projects such as https://github.com/kstenerud/compact-float and https://github.com/kstenerud/compact-time and https://github.com/kstenerud/enctool

https://github.com/kstenerud/dogma has been in development for 4 months and will be released in about a month. This is yet another support project for Concise Encoding (hopefully the last!).

https://github.com/kstenerud/kscrash was in development for about a year and a half before being released.

https://github.com/kstenerud/Musashi took just under a year before its first release as a MAME core (after a TON of testing - I spent 4x more time testing it than I did writing it).

But other smaller things that don't require so much precision I just write up in a couple of weeks and release, such as https://github.com/kstenerud/virtual-builders

The key is to build empathy with your potential users. What will their motivations be that lead them to try out your project? What will they be looking for when they use it? What would someone who has never seen the project before struggle with? (that last one is the hardest because you're so close to the project that it's hard to see what it's like to know nothing about it). These tell you what kind of UX you'll need, what kind of documents you'll need, what kind of tutorials you'll need, how to structure your project for your target audience, etc ("it's for everybody" is never a good idea).

A lot of times it comes down to recruiting people to just try it and do a brain dump of everything that goes wrong or frustrates or confuses them. I've done show-HN posts for things that are unreleased, just to get the valuable criticism. It's nearly impossible to develop good projects in a vacuum.

If you're not posting out of worry for doing it wrong, THAT is doing it wrong. The point is to find out where you're doing it wrong so that you can correct it! And that's where the crowd is a HUGE help.

I got so sick of the broken time formats (ALL of them are broken, including ISO-8601) that I eventually made my own: one in binary [1], and one in text [2].

[1] https://github.com/kstenerud/compact-time/blob/master/compac...

[2] https://github.com/kstenerud/concise-encoding/blob/master/ct...

It's not quite so cut-and-dry. UNIX timestamps unfortunately don't solve the problems of time because they don't contain enough information.

Time is something that developers get wrong more often than any other type. Your time data requirements change as your use case for the time changes.

https://github.com/kstenerud/compact-time/blob/master/compac...