I need to be able to submit a date of birth in a timestamp format,
but of course some people using the app are sure to be older than the Epoch timestamp.
I have a date picker in my app and it will return
year = 1955, day = 02, month = 04
If I pass these to os.time I get nil, but of course if the year is > 1969 I get a timestamp back.
Is there a way to get a negative timestamp for a date older than Epoch?
I’ve just tried it out, and it worked fine:
local myUnixTS = os.time({year = 1955, day = 02, month = 04}) print(myUnixTS) --printed "-465480000"
If this doesn’t work (as your post suggests), then perhaps someone at Corona will need to take a look to find out why. For the record, I’m on build 2014.2393 and on Mac OSX.
FWIW I’m getting a return of nil as well, same as Tim.
Windows 7 64bit build 2014.2393
An old blog post suggests that on windows it may be different, although they do go on to say that it should use the same epoch:
http://coronalabs.com/blog/2013/01/15/working-with-time-and-dates-in-corona/
“As stated above, the basic unit of time for a computer is one second. Both iOS and Android (as well as Mac OS X) are based on operating systems derived from Unix, and in those operating systems the standard “time” function returns the number of seconds since January 1, 1970 at midnight. Microsoft uses a different reference point, but since many apps are built using the language C, which had its origins in Unix, their library also uses this time reference point or Epoch.”
oh duh, I am on a windows machine 
I think it’s time I get a mac since I am heavy in the Corona dev now.
negative timestamp works on the device
Yea, Windows while trying to act like a typical Unix C library just can’t get passed some of it’s hardware issues like the system clock.
I know Windows machines are popular, but having used them, various version of Unix/Linux and Mac’s over the year, the Mac is by far the best “developer’s” machine you can get unless you need to build Microsoft specific stuff or you hook up with certain tools that force you into Windows. Editors, the ability to run a native Apache/PHP/MySQL setup the same way hosts run it make for a strong developers platform.
Rob
Yeah I normally develop on Linux machines, any chance Corona will ever make the leap to Linux?
I don’t want to say never, but given how hard it is to port to a new platform and the engineering resources needed to make it happen, it’s certainly not in the near term plans.
Rob
Regarding Windows, it’s time_t values are definitely based on the standard Unix epoch time of 1970.
http://msdn.microsoft.com/en-us/library/1f4c8f33.aspx
But Microsoft documents that they do not return dates for values less than the Unix time epoch (link below). So, yeah, there is your answer why you’re getting nil.
http://msdn.microsoft.com/en-us/library/bf12f0hc.aspx
Now, I don’t think it’s wrong for Microsoft to do this, because the C standard does not define the type for time_t values. Meaning that it’s actually wrong to assume that time_t is a signed integer.
http://en.cppreference.com/w/c/chrono/time_t
In fact, I remember back during the Y2K fiasco, there was much debate about changing time_t to an unsigned integer so that the next Y2K equivalent in 2038, which is when a 32-bit signed time_t value overflows, could be further delayed. But since Unix developers were using negative time_t values already, that put a stop to that and now we have 64-bit signed integer time_t values instead.
That said, in my opinion, for maximum portability and cross-platform support, you should assume that the valid range of a Unix time value is between 1970 and 2038. Otherwise you may be shooting yourself in the foot on a non-Unix platform that you may want to eventually support.
well the API I am having to connect to, and register users with, requires the DOB to be an int, since birthdays before 1970 produce a negative int it still works fine, just not on windows. not sure why they use int for DOB rather than a datetime but I did not write it.
guess I can make a change and see if they accept my pull request
I’ve just tried it out, and it worked fine:
local myUnixTS = os.time({year = 1955, day = 02, month = 04}) print(myUnixTS) --printed "-465480000"
If this doesn’t work (as your post suggests), then perhaps someone at Corona will need to take a look to find out why. For the record, I’m on build 2014.2393 and on Mac OSX.
FWIW I’m getting a return of nil as well, same as Tim.
Windows 7 64bit build 2014.2393
An old blog post suggests that on windows it may be different, although they do go on to say that it should use the same epoch:
http://coronalabs.com/blog/2013/01/15/working-with-time-and-dates-in-corona/
“As stated above, the basic unit of time for a computer is one second. Both iOS and Android (as well as Mac OS X) are based on operating systems derived from Unix, and in those operating systems the standard “time” function returns the number of seconds since January 1, 1970 at midnight. Microsoft uses a different reference point, but since many apps are built using the language C, which had its origins in Unix, their library also uses this time reference point or Epoch.”
oh duh, I am on a windows machine
I think it’s time I get a mac since I am heavy in the Corona dev now.
negative timestamp works on the device
Yea, Windows while trying to act like a typical Unix C library just can’t get passed some of it’s hardware issues like the system clock.
I know Windows machines are popular, but having used them, various version of Unix/Linux and Mac’s over the year, the Mac is by far the best “developer’s” machine you can get unless you need to build Microsoft specific stuff or you hook up with certain tools that force you into Windows. Editors, the ability to run a native Apache/PHP/MySQL setup the same way hosts run it make for a strong developers platform.
Rob
Yeah I normally develop on Linux machines, any chance Corona will ever make the leap to Linux?
I don’t want to say never, but given how hard it is to port to a new platform and the engineering resources needed to make it happen, it’s certainly not in the near term plans.
Rob
Regarding Windows, it’s time_t values are definitely based on the standard Unix epoch time of 1970.
http://msdn.microsoft.com/en-us/library/1f4c8f33.aspx
But Microsoft documents that they do not return dates for values less than the Unix time epoch (link below). So, yeah, there is your answer why you’re getting nil.
http://msdn.microsoft.com/en-us/library/bf12f0hc.aspx
Now, I don’t think it’s wrong for Microsoft to do this, because the C standard does not define the type for time_t values. Meaning that it’s actually wrong to assume that time_t is a signed integer.
http://en.cppreference.com/w/c/chrono/time_t
In fact, I remember back during the Y2K fiasco, there was much debate about changing time_t to an unsigned integer so that the next Y2K equivalent in 2038, which is when a 32-bit signed time_t value overflows, could be further delayed. But since Unix developers were using negative time_t values already, that put a stop to that and now we have 64-bit signed integer time_t values instead.
That said, in my opinion, for maximum portability and cross-platform support, you should assume that the valid range of a Unix time value is between 1970 and 2038. Otherwise you may be shooting yourself in the foot on a non-Unix platform that you may want to eventually support.
well the API I am having to connect to, and register users with, requires the DOB to be an int, since birthdays before 1970 produce a negative int it still works fine, just not on windows. not sure why they use int for DOB rather than a datetime but I did not write it.
guess I can make a change and see if they accept my pull request