outdated timezones

[mchangrh]

upstream from https://github.com/spencermountain/timezone-soft/issues/9

the current zonefile and aliases are out of date, america/argentina/cordoba is canonical and doesn't exist on zonefile or backwards.json

[mchangrh]

I have spent way too long getting into timezones and naming.

I have a bad version that doesn't follow changes like yours on macos.

what went wrong and why

I went off of the latest freebsd zoneinfo - https://pkgs.org/download/zoneinfo which has historical data, rendering more than 4 lines, which isn't passed to parseTz since it is not 4 lines.

I concede, and instead will just PR fixes for the aliases

latest timezone definitions in the format of iana.js

America/Argentina/Cordoba should be present if the tzdb is up to date.

[spencermountain]

yeah, you're right. this thing is a mess.

I built this timezone-soft library in a rush for a spacetime client - and the only source of truth was ianas-spacetime-knows. I cheated by adding some old ones, and fudging things here and there.

But I think this timezone project is important - and worth doing well. I really appreciate your help. You're right, the library should transform all old mappings into current iana codes, and this subject-matter is particularly dizzying.

I'll release the fixes for America/Indiana/Knox, then we can clean-up which iana codes should be here, and what should be returned in timezone-soft.

I have an ambition to organize the timezones into blocks of same-offset and same-date dst - there's about 30 iana codes that are 'EST' and change on the '2nd sunday of march' since the 70s. I've never seen anybody do this really well. This website seems to be the best reference for this. That would be a beautiful thing to do.

ok, and to address the issue - given that nobody really knows what's going on, I don't mind spacetime supporting some smattering of old timezones - but yeah, we should definitely validate timezone-soft output on the iana codes in your gist. Let me see what I can do today. cheers!

[mchangrh]

Currently, the source of truth that I'm using is the IANA database and if it would make things easier, I can try to create parsers for DST and timezone offsets like I have for all timezones

https://github.com/mchangrh/tzdb-names

That's how I generated the full list and deprecated lists, and hopefully it should be easier to read than zdate

[spencermountain]

ya that would be helpful! My scraper of tzinfo is garbage. also -niles-bot looks neat!

[coatesap]

Hi @spencermountain - is there any appetite to swap this library over to use the Intl API for timezone support, rather than bundling timezone files in the package?

We're currently looking to move away a large application from Spacetime to something like DayJS or Luxon because of the issues and risks around using timezone files that may not be updated regularly (not to mention our responsibility for pulling in these updates to our app at regular intervals).

[spencermountain]

hey Andy, yeah, I plan to either deprecate, or refactor this library once the Temporal API lands. It's looking like it's not until next year now. AFAIK, there's no way to retrieve dst-change dates from the Intl API. cheers

[coatesap]

Maybe I'm misunderstanding what the timezone files are used for. Are they not used to determine the correct new local time when using the goto() method?

[mchangrh]

My issue was with downstream timezone-soft checking against spacetime for valid IANA timezone names.

The timezone files are used for determining dst offset and timezone names (including goto())

eg s.now('America/Indiana/Knox') and then DST offset & rollover dates for that timezone