4 ms·

If you are dealing with timestamps from the past (e.g. birthdays via a datepicker that constructs Date objects), then you should watch out for different browser

If you are dealing with timestamps from the past (e.g. birthdays via a datepicker that constructs Date objects), then you should watch out for different browsers' inconsistent handling of Daylight Savings Time. Moment is really indispensable here, since it includes a database of past years' DST transition dates. I wrote a blog post about it here: https://illuminatedcomputing.com/posts/2017/11/javascript-timezones/ https://illuminatedcomputing.com/posts/2017/11/javascript-ti...

anothergoogler 8y ago
I agree, it's similar to Joda for Java. Sure, Joda does some things that exist in the standard library, but you can be sure that by using Joda that you're getting it right in all kinds of twisted scenarios you never considered.
- merb 8y ago
  actually joda is built into java8+ called java.time
  - anothergoogler 8y ago
    Thanks for the tip, I had no idea and was still including the dependency.
    - rhacker 8y ago
      It's not API compatible, so if you use Joda and you're thinking of using java.time, it's going to be a lot of refactoring.
      - Freak_NL 8y ago
        It's pretty straight forward to migrate from Joda to Java 8's builtin classes though. Just remove the dependency on Joda Time and let the compiler tell you which files to fix. This blog post lists which Java 8 classes replace their Joda Time counterparts: https://blog.joda.org/2014/11/converting-from-joda-time-to-javatime.html https://blog.joda.org/2014/11/converting-from-joda-time-to-j...
        village-idiot 8y ago
        The worst is when you’re stuck on older libraries that still use Joda transitively, so you gotta transition to and from joda at the barriers.
  - azernik 8y ago
    We can only hope moment or at least its API gets similar treatment.
robocat 8y ago
Past time zones should only be a fairly specialist need: our front end code (SPA that is especially in the time domain) doesn't need to deal with past time zones. Then again, although our SPA is 100% JSON, we do all date and time processing at the server. Putting UTC times into our front end would require the front end to know too many business rules. > e.g. birthdays via a datepicker that constructs Date objects > [From your comment in link]: The birthday will be wrong from the very start, because datepickers din't care about people can be born in some TZ and fill forms different TZs. Normally if you're only interested in date only, it doesn't matter if time part is off by hour or more hours. But if you live in Africa, then it could be whole day difference (because of how date will parsed). I have trouble understanding your example - I am guessing you are sending UTC date including time of birth? Seems a little contrived. Maybe pick a better example (calendars or alerts and timezones?) That said, I agree that trusting the browser implementation is mad. We still have clients accessing using IE8 (we just dropped support), Safari 7 (iPhone 4), and a fair number use Chrome 30/33 because that is the version the WebView is stuck on for Android 4.4. Some of our users have the date on their computer set a week out (or more)! Edit: just saw comment at end of your article "If your users enter birthdays with some kind of date picker, you probably suffer from this bug!". I think you just have a problem with your code: you would not use UTC date/time from a date picker, and you should either zero the time component or don't use Date internally when you just need a date - e.g. an input type=date naturally returns "yyyy-mm-dd".
- kbenson 8y ago
  The problem is that if you use a zeroed time component, but at some point it's assumed 00:00:00 (midnight), shifting timezones might mean that it shifts to the previous day. Even if you then truncate the hour portion before display, the date is wrong. For example, you use a datepicker at some point, and it stores 2000-01-01 00:00:00 in the US/Eastern time zone (because that's where you and the computer you're on are when you do it). If you happen to store that as UTC, you might find some interesting outputs for people on the West coast if you convert back to a local (US/Pacific) timestamp. Specifically, you'll get 1999-12-31 21:00:00, and if you do this blindly and throw away the hour portion, you still get the wrong date. When you want dates, you often really want to store just the date potion. Any time you want a date and time, you probably also want a timezone along with it, or at a minimum, you want to know what type of output your use case requires and handle it appropriately. Dates and times are one of those things that seems simple until you've had to deal with the details and encountered the problems enough that you always treat it with a bit of respect.

anothergoogler 8y ago

I agree, it's similar to Joda for Java. Sure, Joda does some things that exist in the standard library, but you can be sure that by using Joda that you're getting it right in all kinds of twisted scenarios you never considered.

merb 8y ago
actually joda is built into java8+ called java.time
- anothergoogler 8y ago
  Thanks for the tip, I had no idea and was still including the dependency.
  - rhacker 8y ago
    It's not API compatible, so if you use Joda and you're thinking of using java.time, it's going to be a lot of refactoring.
    - Freak_NL 8y ago
      It's pretty straight forward to migrate from Joda to Java 8's builtin classes though. Just remove the dependency on Joda Time and let the compiler tell you which files to fix. This blog post lists which Java 8 classes replace their Joda Time counterparts: https://blog.joda.org/2014/11/converting-from-joda-time-to-javatime.html https://blog.joda.org/2014/11/converting-from-joda-time-to-j...
      - village-idiot 8y ago
        The worst is when you’re stuck on older libraries that still use Joda transitively, so you gotta transition to and from joda at the barriers.
- azernik 8y ago
  We can only hope moment or at least its API gets similar treatment.

robocat 8y ago

Past time zones should only be a fairly specialist need: our front end code (SPA that is especially in the time domain) doesn't need to deal with past time zones. Then again, although our SPA is 100% JSON, we do all date and time processing at the server. Putting UTC times into our front end would require the front end to know too many business rules. > e.g. birthdays via a datepicker that constructs Date objects > [From your comment in link]: The birthday will be wrong from the very start, because datepickers din't care about people can be born in some TZ and fill forms different TZs. Normally if you're only interested in date only, it doesn't matter if time part is off by hour or more hours. But if you live in Africa, then it could be whole day difference (because of how date will parsed). I have trouble understanding your example - I am guessing you are sending UTC date including time of birth? Seems a little contrived. Maybe pick a better example (calendars or alerts and timezones?) That said, I agree that trusting the browser implementation is mad. We still have clients accessing using IE8 (we just dropped support), Safari 7 (iPhone 4), and a fair number use Chrome 30/33 because that is the version the WebView is stuck on for Android 4.4. Some of our users have the date on their computer set a week out (or more)! Edit: just saw comment at end of your article "If your users enter birthdays with some kind of date picker, you probably suffer from this bug!". I think you just have a problem with your code: you would not use UTC date/time from a date picker, and you should either zero the time component or don't use Date internally when you just need a date - e.g. an input type=date naturally returns "yyyy-mm-dd".

kbenson 8y ago
The problem is that if you use a zeroed time component, but at some point it's assumed 00:00:00 (midnight), shifting timezones might mean that it shifts to the previous day. Even if you then truncate the hour portion before display, the date is wrong. For example, you use a datepicker at some point, and it stores 2000-01-01 00:00:00 in the US/Eastern time zone (because that's where you and the computer you're on are when you do it). If you happen to store that as UTC, you might find some interesting outputs for people on the West coast if you convert back to a local (US/Pacific) timestamp. Specifically, you'll get 1999-12-31 21:00:00, and if you do this blindly and throw away the hour portion, you still get the wrong date. When you want dates, you often really want to store just the date potion. Any time you want a date and time, you probably also want a timezone along with it, or at a minimum, you want to know what type of output your use case requires and handle it appropriately. Dates and times are one of those things that seems simple until you've had to deal with the details and encountered the problems enough that you always treat it with a bit of respect.