- How do I install glhd/laravel-timezone-mapper?
- Install it with Composer using composer require glhd/laravel-timezone-mapper. Laravel package auto-discovery registers the service provider, so no manual wiring is needed in a standard application. If the package ships a publishable config file, publish it only when you need to override the defaults.
- Does laravel-timezone-mapper work without an external API or internet connection?
- Yes. The package is designed to resolve timezones offline, so it does not make external API calls at runtime. That keeps latency low, avoids API keys and rate limits, and works in private networks or air-gapped environments. You still need to keep PHP and the operating system tzdata current for accurate results.
- Which Laravel versions does glhd/laravel-timezone-mapper support?
- Version 1.5.0 adds Laravel 13 support according to its release notes. Confirm the exact illuminate/support and php constraints in composer.json, because a minor release could widen support for 13 or drop older versions. Run composer why-not glhd/laravel-timezone-mapper 1.5.0 in a scratch branch to check conflicts before upgrading.
- How do I convert latitude and longitude to a timezone in Laravel?
- Pass the latitude and longitude values to the mapper and it returns an IANA timezone identifier such as America/New_York. Use that identifier at the boundaries of your app, for example when pre-filling a user settings form or normalizing partner data. Keep storing UTC timestamps plus the named zone rather than a fixed offset.
- Is the timezone mapper safe for DST edge cases and tzdata changes?
- Timezone correctness depends on the mapping data source and the tzdata available to PHP, not just the package code. DST transitions can produce ambiguous or nonexistent local times, so add tests around known DST boundaries for the zones you care about. Keep the base image and PHP tzdata patched, and refresh the package when mapping data changes.
- Can I use it to map timezone identifiers to display labels or offsets?
- Yes. It can normalize IANA identifiers and help produce display values like offsets or labels for forms, APIs, and user settings. Keep the canonical identifier as the stored value and treat labels as presentation-only. This avoids locking saved data to a particular display format.
- How do I test code that uses laravel-timezone-mapper?
- Test the behavior through your own wrapper or the public API rather than mocking package internals. Use known coordinate and timezone pairs as fixtures and assert the returned IANA identifier. Add a couple of DST-boundary tests, and run them across the Laravel and PHP versions in your CI matrix.
- Will upgrading from 1.4.0 to 1.5.0 break my app?
- It is published as a minor release, so most apps should upgrade without code changes, but verify before merging. Check whether the illuminate/support and php constraints were narrowed, and diff the public API and config keys between 1.4.0 and 1.5.0. Treat any removed method or renamed key as breaking regardless of the version number.
- What are alternatives to glhd/laravel-timezone-mapper?
- Alternatives include GeoIP packages, hosted geolocation or timezone APIs, and rolling your own lookup tables on top of PHP DateTimeZone. Hosted services can be more current but add network calls, keys, and rate limits. This package is a good fit when you want an offline, Laravel-friendly lookup and can keep tzdata current.
- Is glhd/laravel-timezone-mapper actively maintained and production-ready?
- It is a small, single-maintainer package in a correctness-sensitive area, so treat it as a focused utility rather than a platform. Pin the version, wrap direct calls behind a small internal interface, and keep upgrade tests around timezone behavior. Review the repository activity and CI matrix before relying on it in critical paths.