Among other problems: the variables est and estTime are both mis-named. The correct name for "the time in New York" is Eastern Time.
Depending on the time of year, Eastern Time will either match "Eastern Standard Time" or "Eastern Daylight Time". Forcing the time to always be "Eastern Standard Time" means that the times will be offset by an hour from the user's expectation about half of the year.
Arizona Exception: if you're in the boundaries of Arizona, you might need to correctly specify whether you mean a "Standard" time or a time which switches based on Daylight Savings. Different places in the boundaries of Arizona work differently.
Matthalp•3mo ago
Hi @rsclient! Thank you for taking the time to read the post and providing the feedback. I've gone ahead and updated the post and library code based on it.
> the variables est and estTime are both mis-named. The correct name for "the time in New York" is Eastern Time.
Yes, that is a good catch. The variables were mis-named and should have been "eastern" (ET) and "pacific" (PT) and not EST/PST given that "America/New_York" and America/Los_Angeles" were the reference timezone. If someone just wants EST or PST they would need to create a timezone bound to just that. The library supports statically typing either and would prevent EST/ET or PST/PT from being used interchangeably.
> Depending on the time of year, Eastern Time will either match "Eastern Standard Time" or "Eastern Daylight Time". Forcing the time to always be "Eastern Standard Time" means that the times will be offset by an hour from the user's expectation about half of the year.
Yes, agreed. The original naming was not correct and has been fixed.
> Arizona Exception: if you're in the boundaries of Arizona, you might need to correctly specify whether you mean a "Standard" time or a time which switches based on Daylight Savings. Different places in the boundaries of Arizona work differently.
he library should be able to support this behavior, but it would be important for the caller to know what timezone they should be using: (i) Navajo nation would use a timezone bound to "America/Denver and (ii) everywhere else inside would use "America/Phoenix". [1]
> Among other problems
I appreciate you raising the points above! I hope you can see I am open to feedback and take improving this work seriously. If you are wouldn't mind sharing the rest of what you are seeing, I would be interested in hearing more.
rsclient•3mo ago
Depending on the time of year, Eastern Time will either match "Eastern Standard Time" or "Eastern Daylight Time". Forcing the time to always be "Eastern Standard Time" means that the times will be offset by an hour from the user's expectation about half of the year.
Arizona Exception: if you're in the boundaries of Arizona, you might need to correctly specify whether you mean a "Standard" time or a time which switches based on Daylight Savings. Different places in the boundaries of Arizona work differently.
Matthalp•3mo ago
> the variables est and estTime are both mis-named. The correct name for "the time in New York" is Eastern Time.
Yes, that is a good catch. The variables were mis-named and should have been "eastern" (ET) and "pacific" (PT) and not EST/PST given that "America/New_York" and America/Los_Angeles" were the reference timezone. If someone just wants EST or PST they would need to create a timezone bound to just that. The library supports statically typing either and would prevent EST/ET or PST/PT from being used interchangeably.
> Depending on the time of year, Eastern Time will either match "Eastern Standard Time" or "Eastern Daylight Time". Forcing the time to always be "Eastern Standard Time" means that the times will be offset by an hour from the user's expectation about half of the year.
Yes, agreed. The original naming was not correct and has been fixed.
> Arizona Exception: if you're in the boundaries of Arizona, you might need to correctly specify whether you mean a "Standard" time or a time which switches based on Daylight Savings. Different places in the boundaries of Arizona work differently.
he library should be able to support this behavior, but it would be important for the caller to know what timezone they should be using: (i) Navajo nation would use a timezone bound to "America/Denver and (ii) everywhere else inside would use "America/Phoenix". [1]
> Among other problems
I appreciate you raising the points above! I hope you can see I am open to feedback and take improving this work seriously. If you are wouldn't mind sharing the rest of what you are seeing, I would be interested in hearing more.
[1] https://en.wikipedia.org/wiki/Time_in_Arizona