3 ms·
DST and local time are relevant in calculations when humans are involved. A user in Japan shouldn't be told it's still Sunday just because it's still Sunday som
by Kwpolska 3y ago
DST and local time are relevant in calculations when humans are involved. A user in Japan shouldn't be told it's still Sunday just because it's still Sunday somewhere in western Europe. If I set up a recurring meeting every Monday at 10:00, it shouldn't suddenly shift to 09:00 or 11:00 just because of a DST switchover.
- kroolik 3y agoWhat if the meeting is between people in EU and USA, where DST transitions occur at different moments?
- rightbyte 3y agoHmm ... if a problem is hard enough maybe just don't try to solve it? Treat the meeting time as a string, rather than a time, since it is ambiguous anyway what the organizer meant, and let the user figure out what the string means.
- airstrike 3y agoTell those people not to meet at 2am on the night DST changes
- demondemidi 3y agoAll the meetings are hosed for about two weeks. This is a known issue for anyone working with time zones that don’t change together.
- Kwpolska 3y agoCalendars like Outlook let you specify a timezone for the event. If it's set to Europe/Warsaw, the US goes out of sync for a few weeks. If America/New_York, the EU does. This still isn't a problem for a meeting between LA and NY, for example (unless the meeting is in the middle of the night).
- demondemidi 3y agoYep! I hate those few weeks between PST and CET.
- smitty1e 3y agoI didn't say "irrelevant". I questioned keeping that in the library.
- Hackbraten 3y agoIf the library isn't supposed to do all the heavy lifting, then who is?
- smitty1e 3y agoClient code between the specific use-case and the general library is how this is typically done.
- Hackbraten 3y agoSo you actually agree that keeping the policy data in a library is a good thing, you're just saying that it should be a separate library?