0

I built an operational Android app that stores / retrieves data in Firebase. I am now replicating the app in IoS / Swift. On Android I use Java Classes (POJOs) that include Java Date attributes. I store the whole class in Firebase. Below is a screenshot of what Firebase does with a Java Date.

Here are my questions:

  • Although it "Works" is Java Date not supported in FB?
  • If Java Date is supported in FB, will a Swift Class with Date in it inter-operate with the Java-based Dates in Firebase? (I am new to Swift)
  • What is the recommended best practice for Date format "Universality" across IoS and Android? A long int representing UTC?

enter image description here

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
Frank Zappa
  • 451
  • 2
  • 11
  • 23

1 Answers1

2

The Firebase Realtime Database stores JSON types only. There is no native Date type in JSON. So what you actually see in your database are the properties of the Java Date class.

I'll be honest: I'm quite surprised that this works to begin with. Most standard Java classes contain things that are incompatible with Firebase's JSON serialization logic.

But storing dates in this format is really an anti-pattern. You're storing way more information than is needed.

In most cases you should store a timestamp, the number of milliseconds since the epoch, i.e. 1507089082006.

In some cases it may be more convenient to store the date as a sortable string format, i.e. "2017-10-03".

Also see:

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Thank Frank. This is helpful. Storing Java Date in FB has "Worked" for the last 12 months. However, If you are ever creating an "FAQ" :) The reason I need to switch formats is two-fold. 1) Compatibility between Android/IoS and 2) Although the above format "Works" one of the insidious characteristics is...To get the date setup in Java one typically uses Java "Calendar" Well, months in Java Calendar begin with 0. When one then stores that in the above Java Date format (via JSON) to FB...you end up with every month being off by one BUT the time attribute (timestamp/long/epoch) is 100% correct. – Frank Zappa Oct 04 '17 at 03:56
  • Yeah, the idiosyncrasies of date/time classes on various platforms are a great source of entertainment and frustration. It's one of the reasons to not use their internals in permanent storage and always go for either UNIX-style timestamps or lexicographically sortable (ISO-8859) date/time formats. – Frank van Puffelen Oct 04 '17 at 04:27
  • @FrankZappa I have to agree with Frank van Puffelen, in this case, I think the best practice comes from standardized best practices for cross devices communications. In REST the most common scenario is to use String in this form "yyyy-MM-dd". Every language has some way to transform String representing dates in their native Date class. Another advantage of doing this is that format can be sorted even as a String. Great name BTW xD – cutiko Oct 04 '17 at 12:46