Critical problem with datetime precision

[N6REJ]

I'm trying to create a listing & form, that REQUIRE 5-6 digit precision on time.
when I manually change datetime to datetime(6) and then go to the element and format the date and time with time = H:i:s.u
date = Y-m-d H:i:s.u
on save fabrik changes the datetime format back to datetime!

Further the actual time value will need to be computed from a short php script from the data entered because the date is actually part of a EXTREMELY EXACT 80 char fortran string where even spaces matter.
If it helps this is for astronomical observation reports, that go directly to harvard, Nasa & other places.

     K16E86P  C2016 05 08.42226 16 37 40.71 -01 16 31.1          19.4 R      H45
E1354         C2016 05 08.42384 18 17 39.45 +08 56 48.7          15.8 R      H45

is an example of the code that would be entered... these are 2 observations but would be entered in a group like this...

    CK02V010  C2002 11 08.35784 05 02 23.30 +16 23 29.7          16.3 T      H43
    CK02V010  C2002 11 10.34661 04 58 20.01 +16 26 19.2          16.1 T      H43
    CK02V010  C2002 11 10.40306 04 58 12.46 +16 26 24.8          16.1 T      H43
    CK02V010  C2002 11 11.37825 04 56 04.88 +16 27 47.3          16.5 T      H43
    CK02V010  C2002 11 12.35521 04 53 51.08 +16 29 10.6          16.5 T      H43
    CK02V010  C2002 11 12.37199 04 53 48.68 +16 29 11.6          16.5 T      H43
0092P         C2002 11 13.04957 22 58 05.87 -11 10 16.3          15.4 T      H43
0092P         C2002 11 13.06756 22 58 07.63 -11 10 18.7          15.4 T      H43
    CK02V010  C2002 11 13.29381 04 51 37.16 +16 30 31.0          16.6 T      H43
    CK02V010  C2002 11 13.33544 04 51 30.96 +16 30 34.3          16.4 T      H43
    CK02V010  C2002 11 13.36868 04 51 26.00 +16 30 37.2          16.6 T      H43
    CK02V010  C2002 11 17.35332 04 40 51.54 +16 35 57.1          15.2 T      H43
    CK02V010  C2002 11 17.35862 04 40 50.60 +16 35 56.2          13.3 T      H43
    CK02V010  C2002 11 17.38604 04 40 43.47 +16 35 59.9          15.3 T      H43
    CK02V010  C2002 11 19.27512 04 35 07.05 +16 38 11.8          16.3 T      H43
    CK02V010  C2002 11 19.30541 04 35 01.19 +16 38 14.6          15.7 T      H43
    CK02V010  C2002 11 19.33264 04 34 56.17 +16 38 16.1          16.0 T      H43
    CK02V010  C2002 11 19.34892 04 34 53.06 +16 38 16.7          15.6 T      H43
    CK01H50T  C2002 11 19.38187 09 55 18.67 -05 23 02.1          13.8 T      H43
    CK01H50T  C2002 11 20.41244 09 54 41.76 -05 26 02.5          16.3 N      H43
0092P         C2002 11 21.04762 23 12 00.10 -11 16 55.5          16.6 N      H43
0092P         C2002 11 21.08683 23 12 03.91 -11 16 49.3          16.5 N      H43

This code could be several hundred lines long on each entry. Quite often is 100+
How can we get this date issue resolved?

 

[troester]

Try to set "Alter field types" to NO in list/Details/Advanced settings.
This should prevent Fabrik from altering anything in the database settings.

 

[N6REJ]

tyvm!! Does this look like it will be ok? I changed to char type because its 50% faster ( i have 89k records ) and they MUST be a specific count.

 

[cheesegrits]

I can't guarantee that the date element won't mess with your times. I've never seen anyone try and use it for precision timing. You might be better off just using a field element, where we won't do any kind of date/time operations on it, and just treat it like a string.

-- hugh

 

[N6REJ]

so , tell fabrik its a field and leave it as datetime in the db?
I'm also trying to figure out how to parse the entry into single lines and view in ascii format ( <pre></pre> ) as they need to copy it EXACTLY spaces and all, as each line was entered...

I'll be using the date/time for creating lightcurve graphs.

 

[cheesegrits]

I would suggest just leaving it a varchar in the database, and just treat it as a simple string. Unless you have a specific requirement for it to be a datetime field.

-- hugh

 

[N6REJ]

well, I need to be able to display light curves down to the .00001 second.
So, whatever will accomplish that...
one measurement will be magnitude ( nn.n ) and the other will be
PRECISE date/time.
So, what would be best for that.