Hello, 

I have a need to convert a timestamp into a very specific date/time format.  

I need to convert a timestamp into a single string of numbers in this format MMDDYYYHHMM.   Month(2digits) Day(2digitis) Year(4digits) Hour(2digits/24hr clock) Minutes(2digits)  [No separator characters in between any of the groups]

I have no idea where to start on this.  Any ideas on where to begin?  

Field name is :TimeRecieved

Thanks

Chris

What's the TS raw data?

9/5/2018 10:39:21 AM

or 

Different.

Yes.  that's exactly what it looks like.  Sorry for not including that before.  

 

Thanks

Chris

and you want it to look like

090520181039

Yes.  090520181039 would be exactly what my end goal would be.  

 

Thanks Chris

2 hours ago, CKonash said:

I need to convert a timestamp into a single string of numbers in this format MMDDYYYHHMM.  

Assuming you meant "MMDDYYYYHHMM" (i.e. 4 digit year), you could do simply:

SerialIncrement ( "000000000000" ; 10000000000 * Month ( TimestampField ) + 100000000 * Day ( TimestampField ) + 10000 * Year ( TimestampField ) + 100 * Hour ( TimestampField ) + Minute ( TimestampField ) )

 

5 minutes ago, comment said:

Assuming you meant "MMDDYYYYHHMM" (i.e. 4 digit year), you could do simply:

SerialIncrement ( "000000000000" ; 10000000000 * Month ( TimestampField ) + 100000000 * Day ( TimestampField ) + 10000 * Year ( TimestampField ) + 100 * Hour ( TimestampField ) + Minute ( TimestampField ) )

 

Thank you for the reply.  I have never used the SerialIncrement calculation.  Would you mind sharing the rest of your calculation values.  I'll play around with that command in the meantime. 

Thanks again!  Chris

1 minute ago, CKonash said:

Would you mind sharing the rest of your calculation values. 

Not sure what you mean by that. 

2 minutes ago, comment said:

Not sure what you mean by that. 

I'm really sorry.  I didn't see that the window of your reply was able to scroll to the right and show the rest of the calculation.  Sometimes I'm not the most with it somedays...   I really thank you for the help. I'm going to try and implement that and see how it goes.   

 

Hey Comment!  What an elegant way of producing result instead of the old-fashioned and clumsy way of:

Let ( ts = TimeStampField 
;

Right ( "00" & Month ( ts ) ; 2 ) &
Right ( "00" & Day ( ts ) ; 2 ) &
Right ( "0000" & Year ( ts ) ; 4 ) & 
Right ( "00" & Hour ( ts ) ; 2 ) &
Right ( "00" & Minute ( ts ) ; 2 )

)

Nicely done!

Edited September 5, 20187 yr by LaRetta
removed seconds and corrected hour

Look who came out of retirement!!!  Welcome back Comment!!! 

Long time no post .  Question for you you, if you don't mind.

Why do you need the SerialIncrement function at all?  It seems like :

Quote

10000000000 * Month ( TimestampField ) + 100000000 * Day ( TimestampField ) + 10000 * Year ( TimestampField ) + 100 * Hour ( TimestampField ) + Minute ( TimestampField )

gives the same result.

Just wondering if I'm missing something.

 

Thanks

Steve

 

Edited September 5, 20187 yr by Steve Martino
additional info

10 minutes ago, Steve Martino said:

Why do you need the SerialIncrement function at all? 

To get the leading zero when the month is a single digit (as it is now). Your calculation will return the same result only for the months of October, November and December.

 

12 minutes ago, Steve Martino said:

Look who came out of retirement!!! 

We'll see about that...

I'm not sure if I should be happy about the you "coming out of retirement" or if I should feel bad for blowing the cover off of your summer vacation of hiding...   

Thanks again Comment!

You're making the world a better place by helping people.  Everyone should follow in your footsteps and we would have a better place to live.   

Chris

 

22 minutes ago, LaRetta said:

instead of the old-fashioned and clumsy way

Well, if you had said:

SerialIncrement ( "00" ; Month ( TimestampField ) )
&
SerialIncrement ( "00" ; Day ( TimestampField ) )
&
Year ( TimestampField ) 
&
SerialIncrement ( "00" ;  Hour ( TimestampField ) )
&
SerialIncrement ( "00" ;  Minute ( TimestampField ) )

I wouldn't argue mine was better. But SerialIncrement() exists since version 7, using Right() for padding is really old.

Ahh  I see it now (after testing).  Thanks.

5 minutes ago, CKonash said:

I'm not sure if I should be happy about the you "coming out of retirement" or if I should feel bad for blowing the cover off of your summer vacation of hiding...   

Thanks again Comment!

You're making the world a better place by helping people.  Everyone should follow in your footsteps and we would have a better place to live.   

Chris

 

Looks like the challenge was too (hard for us) easy to resist!

Edited September 5, 20187 yr by Steve Martino

2 minutes ago, comment said:

But SerialIncrement() exists since version 7, using Right() for padding is really old.

True, although few Developers even today take advantage of SerialIncrement() in this way. I surely miss being nudged by you.  😀

I'm going to humbly argue that Right() might be the better choice here. LaRetta is probably correct that few developers use SerialIncrement this way -- and that's the problem. I need other developers to be able to read my code, so when possible I try to make it obvious.

Exceptions would be:

- when working in a dev. environment where something like this has been adopted as a standard

- when performance is an issue

 

 

Great Monty Python, Tom!  As for code, how will SerialIncrement() become the norm if we don't suggest it and use it?  Dumbing down code so it can be read by even beginner Developers doesn't seem appropriate; rather, I think we should educate beginner Developers and nudge them to step up their game, just as Comment did for me ... just my opinion of course.

I know that, even when new to FileMaker, I didn't seek out those who taught inefficient and clumsy code but rather those that taught elegant and efficient calculations.  While true that clarity is more important than brevity, we all need to learn various methods.  For myself, I would probably prefer Comment's second calculation.

By the way, just because I would use the second calculation for this specific situation, I would use Michael's first calculation for many other situations.  We can't have too many tools in our toolkits.