-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow timezone to be specified for expiresAt values #112
Comments
It seems that specifying a custom timezone would cause problems when daylight saving happens. For instance, in PST vs PDT - if a user were to set a custom timezone of -7 on their caching TTL but then it is the same evening that -8 switches over, that could cause some problems on when the cache is reset. |
That should be the responsibility of the developer using this feature. |
This change introduces a 'timezone' option for cache policy objects that determines which time zone the 'expiresAt' time is relative to. Time zones may be specified either as a fixed offset (ex. -0800) or as a IANA time zone name (ex. America/Los_Angeles). When using a named time zone, daylight savings time will be accounted for automatically. Closes hapijs#112.
This change introduces a 'timezone' option for cache policy objects that determines which time zone the 'expiresAt' time is relative to. Time zones may be specified either as a fixed offset (ex. -0800) or as a IANA time zone name (ex. America/Los_Angeles). When using a named time zone, daylight savings time will be accounted for automatically. Closes hapijs#112.
I changed my mind about this. I don't want to support timezones anymore. |
This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions. |
Moved here from hapijs/hapi#1748
The text was updated successfully, but these errors were encountered: