move isAutoTimeAndDate / isAutoTimeZone from react-native-device-info

[mikehardy]

Summary

Howdy @zoontek :-) - this module (which I use and which is fantastic by the way) already has time and date information in it and does it well

react-native-device-info also had some duplicate time and date functions, plus these 2 which were unique

I'd like to have one place in the react-native-community for this type of information and this seems like a natural home

So I'm purging them out of react-native-device-info in preference to here

There was no iOS implementation of them in react-native-device-info (maybe it is not possible? unknown) so this is the complete implementation, such as it is

I did not add it to the changelog as requested in this template because I could not see a changelog?

Test Plan

I added it to the Sync and Async example. Seems to work? Although getting the example to work with local code changes required me to run yarn add "file:../" before it would pick up changes...

What's required for testing (prerequisites)?

What are the steps to reproduce (after prerequisites)?

Compatibility

OS	Implemented
iOS	❌
Android	✅

Checklist

• I have tested this on a device and a simulator
• I added the documentation in README.md
• I mentioned this change in CHANGELOG.md
• I updated the typed files (TS and Flow)
• I added a sample use of the API in the example project (example/App.js)

[mikehardy]

Thanks for considering this and after you think on it I will of course make whatever changes you like so the code is comfortable over here. I'm doing a little research on iOS APIs too, maybe we can actually have an implementation for iOS who knows?

[mikehardy]

Okay, I searched through the API docs from Apple, and couldn't find anything. I asked the original author of the API here in case they know react-native-device-info/react-native-device-info#583 (comment) - but I think this is simply not available on iOS, so once you decide exactly how you want to specify returns for platform-specific stuff I'll shape this up for a second review. Thanks @zoontek

[zoontek]

@mikehardy I would rather go with:

type Option<T> = T | undefined

usesAutoDateAndTime(): Option<boolean>
usesAutoTimeZone(): Option<boolean>

I find it less confusing 🙂

[mikehardy]

got it! I will do exactly that. Also the author of the original PR researched and came to the same conclusion I did - there is simply no API for iOS for these, so we're not missing anything - the PR is multi-platform "complete" such as it is. I'll tag you when I've pushed and feel like this is ready. Thanks!

[mikehardy]

Okay @zoontek I think it's ready for a look again, here are the changes I made - some of which were in existing code, all with the idea of API-similarity:

• I added the Option<boolean> type you asked for, *and I updated your existing boolean-APIs to also return it (I think you'll like that? But I could be wrong)
• I altered these two APIs to be called usesXXX instead of isXXX, because your other boolean-APIs started with uses, not is (Again, I think you'll like that? But I could be wrong)

Let me know what you think!

[zoontek]

Looks pretty good except that uses24HourClock and usesMetricSystem returns a boolean 100% of the time on all platforms, so no need to wrap them in a Option 😅

EDIT: I can merge it and make the changes if you want

[mikehardy]

@zoontek I just pushed that up with the original two methods untouched, and just my proposed additions as the 'Option' :-)

[zoontek]

Perfect, I merge it :)

[mikehardy]

Wait! I always re-re-read things (can't help it) and I noticed I still had index.js with the Option wrapping in the function definitions, sorry! easy fix at least

[zoontek]

@mikehardy I will cleanup that before the release, no problem

[zoontek]

@mikehardy It's released: https://github.com/react-native-community/react-native-localize/releases/tag/1.2.0 :)

[mikehardy]

Sweet! Thank you so much @zoontek - react-native-device-info v3 will be out shortly then I think

[mashad6]

Is it gonna be on IOS any time soon?

[mikehardy]

@mashad6 just as soon as someone figures out 1) if it is possible then 2) proposes a PR to implement it I think. Could be as soon as today if you put in the effort and do it, in my experience @zoontek reviews + merges + releases things really fast when people put in the effort to contribute