91–100 of 167 posts
Earlier quoted context omitted.
Kind of funny that you think the open web still exists. I mean, even Microsoft gave up and just went with Chromium, and they got the definition of almost infinite resources at their disposal. Effectively if your website doesn't run in Chrome and Safari, it won't be seen by 99% of the market.
> even Microsoft gave up Ah yes, Microsoft, the defenders of the free world.
Earlier quoted context omitted.
> on a language without a standard library? Because the other languages & with bigger runtimes and more comprehensive standard libraries such as Java applets, Microsoft Silverlight, Macromedia Flash that were promoted for browsers to create "rich fat clients" were ultimately rejected for various reasons. The plugins had performance problems, security problems, browser crashes, etc. Java applets was positioned by Sun…
> other languages & with bigger runtimes and more comprehensive standard libraries such as Java Java's Date standard lib was awful for 2 decades, so there's no guarantee that a big standard library is a good standard library.
Hang on, slashes and year-month-day? https://en.wikipedia.org/wiki/ISO_8601 Handed down by the ISO, The Great Compromise allows YYYY-MM-DD (or YYYYMMDD if you're in a hurry) but the version with slashes I'd find ambiguous and upsetting, especially early in the month. The standard is good, and you can get it from `date -I`. Hell mend anyone who messes with the delimiters or writes the year in octal or any other heresy…
Pro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.
Earlier quoted context omitted.
Pro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.
I disagree, store UTC time and the name of timezone it was originally recorded in so it can be translated back to that as well. UTC only loses information.
Earlier quoted context omitted.
Proer tip: never use anything but unix timestamp until presentation.
There's no reliable way to map it back into the local time in the past, unless you also safe the UTC offset.
Earlier quoted context omitted.
Proer tip: never use anything but unix timestamp until presentation.
This is great until someone asks whether a particular event happened before or after lunch.
Earlier quoted context omitted.
Pro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.
What if you're storing a calendar date, such as a birthday? A timestamp is inappropriate, and it's meaningless to discuss timezones in this context. (Example - you want to know if a person is old enough to buy cigarettes, and you need to store a birthday that you can compare against the current day to see if they're legally 18 - if you store an epoch at UTC, do you store the time of day they were born? That's not the…
What are best practices/tips on handling date and time everyone has in general? Every time it is a bit of a nightmare.
- Understand the semantic difference between a timestamp (absolute time) and clock/calendar time (relative time). Understand which one your use case uses. Don't use one to store the other.
- If the use case calls for a relative time, do not manually construct or edit the date. Use your platforms date-creation/modification APIs, no matter how unnecessary they seem.
- Understand what is inside your platform's date types at rest. Understand which of your platform's date APIs pull in environmental information (time/tz/locale), as opposed to only using the arguments you pass it. Understand that your platform's 'print/stringify' function may be one of those aforementioned functions. Misunderstanding this often leads people to say inaccurate things. E.g. say your platform has a Date object that stores an epoch-based timestamp. People may say "the Date object is always in UTC", when really the Date object has no time offset, which is not the same thing.
- Understand that if you pass a date around platforms, it might accidentally be reserialized into the same absolute time, but a different relative time.
- Understand that there is a hierarchy of use cases, where each one has more complex requirements:
1. "Create/modify" timestamps; egg timers. (absolute time)
2. Alarm clocks (same clock time always).
3. One-time calendar events (has an explicit, static tz; same clock time if the user changes its day or time zone; different clock time if the user's time offset changes)
4. Recurring calendar events (same as above, except don't change the clock time if the user's time offset changed due to DST, as opposed to a geographic change)
5. Recurring calendar event with multiple participants (same as above, just remember that the attached tz is based on the creator, so the clock time will shift during DST for participants in a place without matching DST rules).
Note that a lot of platforms nowadays have built-in or 3rd party packages that automatically handle a lot of the rules in the above use cases.
Finally, understand that all those little weird things about dates (weird time zones, weird formatting conventions, legislative time zone changes, retroactive legislative time zone changes, leap days, leap seconds, times that don't exist), are good to know, but they will mostly be accounted for by the above understandings. You can get into them when you want to handle the real edge cases.
What are best practices/tips on handling date and time everyone has in general? Every time it is a bit of a nightmare.
Being available everywhere (as far as browsers are concerned) trumps almost all other factors.