You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Even though TZDate has a complete API, developers rarely use the formatter functions outside of debugging, so we recommend you pick the more lightweight TZDateMini for internal use. However, in environments you don't control, i.e., when you expose the date from a library, using TZDate will be a safer choice.
This made me think I ought to use TZDateMini in my app since I have full control over how date objects are used (as is the case for many apps). The problem is that, if I use { in: tz(..) } anywhere in the app, I will end up depending on TZDate and thus lose out on any benefit of using TZDateMini. So, unless I'm missing something, TZDateMini seems impractical for most use cases.
The text was updated successfully, but these errors were encountered:
From the readme:
This made me think I ought to use TZDateMini in my app since I have full control over how date objects are used (as is the case for many apps). The problem is that, if I use
{ in: tz(..) }
anywhere in the app, I will end up depending onTZDate
and thus lose out on any benefit of usingTZDateMini
. So, unless I'm missing something,TZDateMini
seems impractical for most use cases.The text was updated successfully, but these errors were encountered: