Isn't the ScheduleTime class doing redundant work? Why bother keeping a dictionary, dealing with ints and strings when you can directly use strftime/strptime?
Except for the friday/fri thing, which, to be honest, I don't see the point of. I'd rather have uniformity in my code.
getTimezoneOffset() would return the value after taking care of DST. So there shouldn't be any DST related inconsistencies. Now if the user moves to another timezone, and never hits one of our page, there is no direct way of tracking his/her change in location.
I mean that starting mid-March a user who had previously been in a -8:00 UTC offset would then be in a -7:00 UTC offset and you wouldn't know the timezone offset changed until they visited the website again.
That’s certainly a problem. But this solution is better than being totally off. Worst case the person gets the mail in the previous timezone he registered which should be before the DST.
When it comes to scheduling emails, what we want is user's to get emails at a specific time as exactly as possible. For this all we need is the UTC timezone offset including DST, which javascript gives us.
The jstimezonedetect script is a good one if we wan't to know the real timezone. Problem here is we wouldn't know how often this script could remain updated. Any change in DST will have to be provided by the script which if it doesn't there will be in-accuracies. Not to mention the trouble of keeping the script updated. But in general, the script is indeed awesome.
Except for the friday/fri thing, which, to be honest, I don't see the point of. I'd rather have uniformity in my code.