Zeroclickinfo-goodies: TimezoneConverter: Needs to check if Daylight Savings is in effect and adjust answer

[unhammer]

I typed 11:00 EST and got tricked into getting an hour late because apparantly that time zone is called "EDT" when it's winter. Sites like
http://www.worldtimebuddy.com/est-to-cet-converter auto-correct for DST where&when applicable; it'd be cool if ddg could do the same (with a notice, of course, about the auto-correction happening)

---

IA Page: http://duck.co/ia/view/timezone_converter
Maintainer: @GlitchMr

[GuiltyDolphin]

@unhammer Hmm... What about if it mentioned that EST was not in effect at the moment? And (possibly) _suggested_ EDT. This way people can still _access_ the conversion for any of the time zones, but would be informed when that time zone is in effect.

@GlitchMr if we action this, I would recommend we enforce this for _all_ time zones - not just EST/EDT; there are various other time zones with a Daylight Saving Time offset.

[unhammer]

@GuiltyDolphin sure, or it could show both at once (zero-click!)

Also, I did mean that it should work for all time zones … :)

[moollaza]

@duckduckgo/duckduckhack-contributors we need someone with a bit of Perl experience to tackle this super important bug.

We're showing the wrong answer to our users once Daylight Savings comes in effect. This is unacceptable and needs to be fixed ASAP!

Note: This problem also affects our Sunrise Goodie!

[DGMurdockIII]

if have found these TimezoneConverter code https://github.com/filiph/tmzns and https://github.com/google/cctz and https://www.iana.org/time-zones

[mintsoft]

If no-one else can pick this up, I can take a swing at it. I'm confused as to the actual problem though; for queries such as 11:00 EST if the regions that use EST are currently using EDT due to daylight savings time we want to assume EDT instead of EST?

Putting it in my timezones if during the summer someone asks for 13:00 GMT we will assume they meant 13:00 BST instead?

[unhammer]

@mintsoft so my timezone is CET/CEST. Currently, if I ask for 11:00 EST, I see 18:00 CEST which is very misleading. I'd prefer if I saw something like:

17:00 CEST

_Convert Timezone: 11:00 EDT (UTC-4) to CEST (UTC+2)_

_Assuming_ daylight saving – _result is 18:00 CEST if you really meant EST_

[mintsoft]

@unhammer to clarify, you're saying that the problem is that the current DST state of the person querying isn't taken in account?

[unhammer]

@mintsoft "CEST" was auto-guessed by ddg (I only typed 11:00 EST). So In this case, it was only that the current DST state of the place with the same timezone I typed wasn't taken into account. But if I had typed 11:00 EST in CET I also would have preferred to see the DST versions (with a comment about the "autocorrect").

[mintsoft]

@unhammer thanks for the clarification, that makes more sense

[moollaza]

But if I had typed 11:00 EST in CET I also would have preferred to see the DST versions (with a comment about the "autocorrect").

This is the big issue IMO. Users assume that "EST" will be adjusted to "EDT" (during daylight savings) and they think we're wrong when we show them the time in EST because they're expecting it to be "EDT"

Google normalizes this, but doesn't really clarify what they've done for the user:

https://encrypted.google.com/search?hl=en&q=current%20time%20in%20EST

In this case, they normalize the result to ET (adjust the result for EDT), because EST doesn't really make sense during DST.

_wow, that's a lot of acronyms..._

[mintsoft]

OK, so I think maybe we can do something like queries for EDT or EST (for example) is always answered as "ET" (Eastern Time). Eastern Time, will be EDT or EST depending on which is in effect.

Then, unlike G, we can explain what we've actually done rather than leaving the user guessing as to why they've been given a different answer than the question they've asked.

[Throne3d]

I agree that it's important to clarify, especially if there's autocorrect behavior – Phoenix, Arizona is in the MST timezone and doesn't have DST, so if someone does write (and mean) "current time in MST" in the context of Arizona (or at least Phoenix, Arizona), it should be clear that their search wasn't interpreted as they wrote it. (Or, well, if they wrote "14:28 BST to MST" and it assumed they meant "14:28 BST to MT".)

Google's behavior for "current time in MST" is to autocorrect to MT and accordingly display the MDT time during summer times, and for "current time in Arizona" is to display the two timezones – Mountain without DST through most of the state, Mountain with DST in the Navajo Nation – with the first one more prominently available.

[abrahimladha]

Is this issue still open? Here are my results:

[BillyBarbaro]

Hi @abrahimladha if you check out the README for the project, they're currently in Maintenance Mode. For more information you can check out the DuckDuckHack Homepage